د اپلوډ په برخو لوستل chunked HTTP ته اړتیا نلري

نه. یو کلاینټ کولای شي لوی فایل په کوچنیو بفرونو کې ولولي او د پیژندل شوي Content-Length سره یې واستوي. محدود لوستل د حافظې کارول کنټرولوي؛ HTTP چوکاټ کول ترلاسه کوونکي ته وایي چې د غوښتنې بدن چیرته پای ته رسیږي.

یو ثابت فایل چې د هغه بایټ اوږدوالی د HTTP کتابتون پیژني، له هغه جنریټر څخه توپیر لري چې نامعلومه اندازه معلومات تولیدوي. د دواړو سرچینو لپاره د کتابتون لخوا ملاتړ شوی بدن انټرفیس وکاروئ. یوازې د اوږدوالی ورکولو لپاره اړینه نه ده چې ټول فایل په یوه تار کې سره یوځای کړئ.

د HTTP/1.1 لپاره، د پروتوکول د قواعدو له مخې هغه چوکاټ کول وګورئ چې واقعاً لیږل کیږي: Content-Length یا chunked transfer coding. Chunked کوډ کول د فایل د منځپانګې څخه بهر د اندازې نښې زیاتوي. متضاد چوکاټ ساحې مه یوځای کوئ او د پروکسي قناعت ورکولو لپاره چې اپلوډ ومني، اوږدوالی مه اټکل کوئ.

که د پروکسي له لارې اپلوډ ناکام شي، د HTTP نسخه، د بدن سرچینه او لومړۍ رد ثبت کړئ. 411 ځواب د بدن په مینځ کې د تړل کیدونکي اړیکې څخه جلا څیړنې ته اشاره کوي. که پرځای یې د تصدیق بیا هڅې ناکامې شي، وګورئ ایا د اپلوډ بدن بیا غږول کیدای شي. د اپلیکیشن د لوستلو بفر اندازه بدلول ممکن د غوښتنې چوکاټ کول په هماغه توګه پریږدي.

د دې مشاهدې لپاره لاره مهمه ده. ساده متن لیږد د اپلوډ HTTP چوکاټ پروکسي ته ښکاره کوي؛ عادي پای-تر-پای HTTPS هغه د تونل دننه ځای پرځای کوي. HTTP/2 خپل چوکاټ کاروي. له همدې امله د Squid تاریخي محدودیتونه ځینې زاړه ناکامۍ تشریح کوي، نه دا قاعده چې هر اوسنی پروکسي سټریم شوي اپلوډونه ردوي.