قراءة الرفع على أجزاء لا تتطلب HTTP مجزّأ
افصل قراءات التطبيق المحدودة عن تأطير رسائل HTTP/1.1 عندما يتصرف الرفع بشكل مختلف عبر وكيل أمامي.
لا. يستطيع العميل قراءة ملف كبير في مخازن مؤقتة صغيرة وإرساله بطول محتوى معروف. القراءات المحدودة تضبط استهلاك الذاكرة؛ وتأطير HTTP يخبر المستلم أين ينتهي جسم الطلب.
الملف المستقر الذي تعرف مكتبة HTTP طوله بالبايت يختلف عن مولّد ينتج كمية غير معروفة من البيانات. استخدم واجهة الجسم التي تدعمها المكتبة لكلا المصدرين. لا تحتاج إلى تجميع الملف كله في سلسلة نصية فقط لتوفير طول.
بالنسبة إلى HTTP/1.1، افحص التأطير المرسل فعلاً: Content-Length أو ترميز النقل المجزّأ وفق قواعد البروتوكول. يضيف الترميز المجزّأ علامات حجم خارج محتوى الملف. لا تدمج حقول تأطير متناقضة ولا تخمّن طولاً لإقناع وكيل بقبول الرفع.
إذا فشل رفع يمر عبر وكيل، سجّل إصدار HTTP ومصدر الجسم وأول رفض. استجابة 411 تشير إلى تحقيق مختلف عن اتصال يُغلق في منتصف الجسم. إذا فشلت بدلاً من ذلك محاولات إعادة المصادقة، تحقق من ما إذا كان جسم الرفع قابلاً لإعادة الإرسال. قد يترك تغيير حجم مخزن القراءة في التطبيق تأطير الطلب كما كان تماماً.
المسار مهم لتلك الملاحظة. تمرير النص الصريح يكشف تأطير HTTP الخاص بالرفع للوكيل؛ أما HTTPS العادي من طرف إلى طرف فيضعه داخل نفق. يستخدم HTTP/2 تأطيره الخاص. لذا تفسّر قيود Squid التاريخية إخفاقات قديمة معينة، لا قاعدة بأن كل وكيل حالي يرفض الرفع المتدفق.