اپ لوڈ کو ٹکڑوں میں پڑھنے کے لیے Chunked HTTP ضروری نہیں

نہیں۔ کلائنٹ بڑی فائل کو چھوٹے بفرز میں پڑھ کر معلوم Content-Length کے ساتھ بھیج سکتا ہے۔ محدود ریڈنگ میموری کے استعمال کو کنٹرول کرتی ہے؛ HTTP فریمنگ وصول کنندہ کو بتاتی ہے کہ درخواست کا باڈی کہاں ختم ہوتا ہے۔

ایک مستحکم فائل جس کی بائٹ لمبائی HTTP لائبریری کو معلوم ہو، ایسے جنریٹر سے مختلف ہے جو نامعلوم مقدار میں ڈیٹا پیدا کرتا ہے۔ دونوں ذرائع کے لیے لائبریری کا معاون باڈی انٹرفیس استعمال کریں۔ صرف لمبائی دینے کے لیے پوری فائل کو ایک سٹرنگ میں جوڑنے کی ضرورت نہیں۔

HTTP/1.1 کے لیے، وہ فریمنگ دیکھیں جو واقعی بھیجی گئی: پروٹوکول کے قواعد کے تحت Content-Length یا chunked transfer coding۔ Chunked کوڈنگ فائل کے مواد سے باہر سائز کے نشانات شامل کرتی ہے۔ متضاد فریمنگ فیلڈز کو یکجا نہ کریں اور proxy کو اپ لوڈ قبول کرنے پر آمادہ کرنے کے لیے لمبائی کا اندازہ نہ لگائیں۔

اگر proxy کے ذریعے اپ لوڈ ناکام ہو تو HTTP ورژن، باڈی کا ذریعہ اور پہلی مستردگی ریکارڈ کریں۔ 411 جواب ایسی تحقیقات کا اشارہ دیتا ہے جو باڈی کے درمیان بند ہونے والے کنکشن سے مختلف ہے۔ اگر اس کے بجائے authentication کی دوبارہ کوششیں ناکام ہوں تو دیکھیں کیا اپ لوڈ باڈی دوبارہ چلائی جا سکتی ہے۔ ایپلیکیشن کے ریڈ بفر کا سائز بدلنے سے درخواست کی فریمنگ بالکل ویسی ہی رہ سکتی ہے۔

اس مشاہدے کے لیے راستہ اہم ہے۔ سادہ متن میں فارورڈنگ اپ لوڈ کی HTTP فریمنگ proxy کے سامنے ظاہر کرتی ہے؛ عام end-to-end HTTPS اسے سرنگ کے اندر رکھتا ہے۔ HTTP/2 اپنی فریمنگ استعمال کرتا ہے۔ اس لیے Squid کی تاریخی محدودیتیں کچھ پرانی ناکامیوں کی وضاحت کرتی ہیں، یہ قاعدہ نہیں کہ ہر موجودہ proxy اسٹریم شدہ اپ لوڈ مسترد کرتا ہے۔