د HTTP اپلوډ وقفې او Expect: 100-continue

د Expect: 100-continue تبادله وپېژنئ او د هغې لنډ تصمیم ټکی له هغه اپلوډ څخه جلا کړئ چې د معلوماتو لېږد پر مهال بند شوی وي.

اتړ پرانیستل کېږي. د غوښتنې سرلیکونه وځي. داسې ښکاري چې فایل نه خوځېږي. یو توضیح دا دی چې کلاینټ د خپل بدن له لېږلو مخکې د Expect: 100-continue لپاره ځواب ته انتظار دی.

دا میکانیزم ترلاسه کوونکي ته اجازه ورکوي چې غوښتنه د هغې له سرلیکونو څخه رد کړي، مخکې له دې چې احتمالاً لوی اپلوډ ولېږل شي. عادي بریالۍ ترتیب دا دی:

request headers → 100 Continue → request body → final response

100 معلوماتي دی: کلاینټ ته اجازه ورکوي چې مخکې لاړ شي، مګر دا نه مانا لري چې فایل ساتل شوی یا د اپلیکیشن عملیات بریالي شوي. Git push چې HTTP 417 بېرته راګرځوي، د تمې د ناکامۍ یوه مشخصه بېلګه ده.

ومومئ چې کلاینټ کوم ځواب ترلاسه کړ

مشاهدهڅه باید وڅېړل شي
100 Continueکلاینټ کولی شي د بدن سره مخکې لاړ شي
د بدن څخه مخکې وروستی ردعملیات د سرلیک په پړاو کې رد شو
تمه شوی منځنی ځواب نشتهد کلاینټ د انتظار تګلاره او په هغه لاره کې سمبالښت

curl د expect-continue انتظار لپاره جلا تنظیم لري. که هغه libcurl انتظار پرته له تمه شوي ځواب پای ته ورسېږي، هغه بیا هم بدن لېږي؛ پای ته رسېدل په خپله د ټول لېږد ناکامي نه ده. دا تنظیم د ټول لېږد لپاره د اجازه شوي وخت څخه جلا دی. د وروستي زیاتول کېدای شي هغه لومړنۍ وقفه بې توضیحه پرېږدي.

دا هم وپېژنئ چې کومه HTTP خبرې اترې Expect لېږي. د HTTPS منزل ته د عادي CONNECT سره، د وېبسایټ اپلوډ تبادله د TLS دننه ده؛ فارورډ پروکسي د هغې داخلي د تمې سرلیک په ساده ډول نه ګوري. د مخنیوي یا ساده متن د لېږد لاره بېله ده.

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

اړوندې مقالې