לא. לקוח יכול לקרוא קובץ גדול במאגרים קטנים ולשלוח אותו עם Content-Length ידוע. קריאות מוגבלות שולטות בצריכת הזיכרון; מסגור HTTP אומר לנמען היכן גוף הבקשה מסתיים.

קובץ יציב שספריית ה-HTTP יודעת את אורכו בבייטים שונה ממחולל שמייצר כמות נתונים לא ידועה. השתמשו בממשק הגוף הנתמך על ידי הספרייה לשני המקורות. אין צורך להרכיב את כל הקובץ למחרוזת רק כדי לספק אורך.

עבור HTTP/1.1, בדקו את המסגור שנשלח בפועל: Content-Length או קידוד העברה מקוטע לפי כללי הפרוטוקול. קידוד מקוטע מוסיף סמני גודל מחוץ לתוכן הקובץ. אל תשלבו שדות מסגור סותרים ואל תנחשו אורך כדי לשכנע פרוקסי לקבל את ההעלאה.

אם העלאה דרך פרוקסי נכשלת, תעדו את גרסת ה-HTTP, מקור הגוף והדחייה הראשונה. תגובת 411 מרמזת על חקירה שונה מחיבור שנסגר באמצע גוף. אם במקום זאת נכשלים ניסיונות אימות חוזרים, בדקו האם ניתן לנגן שוב את גוף ההעלאה. שינוי גודל מאגר הקריאה של היישום עשוי להשאיר את מסגור הבקשה בדיוק כפי שהיה.

המסלול חשוב לתצפית הזו. העברה בטקסט גלוי חושפת את מסגור ה-HTTP של ההעלאה לפרוקסי; HTTPS רגיל מקצה לקצה מכניס אותו למנהרה. HTTP/2 משתמש במסגור משלו. לכן מגבלות Squid ההיסטוריות מסבירות כשלים ישנים מסוימים, ולא כלל שכל פרוקסי כיום דוחה העלאות בזרימה.

מאמרים קשורים