کله چې ډاونلوډ شوی فایل د HTTP د حالت له کرښې سره پیل شي

که چېرې د PDF یا سپريډ شیټ په څېر فایل د HTTP/1.1 200 OK سره پیل شي، ډاونلوډر د فایل پرځای خام ځواب خوندي کړی دی. دا سکیماتیک ځواب یوازې څلور بایټ منځپانګه لري:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

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

د عادي ډاونلوډ لپاره، له خام ساکټ څخه فایل ته کاپي کول د HTTP کلاېنټ د ځواب-بدن انٹرفېس سره بدل کړئ. د هغې پراکسي تنظیم کړئ، وروستی حالت تایید کړئ او بدن موقت آوټ پوټ ته سټریم کړئ. کلاېنټ د پیغام چوکاټ سمبالوي: د اوږدوالي له مخې محدود، چنک شوي او د اړیکې له مخې محدود بدنونه بېلابېل پارس کول غواړي.

د منځپانګې انکوډنګ بله طبقه ده. د کلاېنټ د مستند شوي رفتار په کارولو سره پرېکړه وکړئ چې ایا تاسو ته ډیکوډ شوي فایل بایټونه غواړئ که په صراحت غوښتل شوې خامه منځپانګه. کمپرېس شوي بایټونه په اتوماتيک ډول د پراکسي خرابي نه ده.

که اپلیکیشن باید د ساکټ کچې کوډ وساتي، نو د هغو ټولو پارس کولو قواعدو او همدارنګه د لوستلو او لیکلو سمبالښت مسؤلیت پرې دی. یوازې هغه بایټونه ولیکئ چې لوستل واقعاً بیرته راوړي، نه د بفر ظرفیت، او جزوي لیکنې سمبال کړئ. که نه، زاړه بفر منځپانګه کولای شي حتی په سمه توګه ایستل شوی بدن هم خراب کړي.

HTTPS له CONNECT ځواب لرې کولو څخه ډېر څه غواړي: د تونل له بریالۍ جوړېدو وروسته، د منزل TLS جوړ کړئ او بیا داخلي HTTP ځواب پارس کړئ. د پراکسي د سرلیکونو وروسته انکریپټ شوي بایټونه د ډاونلوډ وړ فایل نه دي.

ناکام یا نیمګړی آوټ پوټ د موقت نوم لاندې پرېږدئ. یوازې هغه وخت خپور کړئ چې لیږد او د فایل ګوتې بریالۍ شي؛ تش نه فایل بشپړ ډاونلوډ نه ثابتوي.