HTTP اپ لوڈ کی وقفے اور Expect: 100-continue

Expect: 100-continue کے تبادلے کو پہچانیں اور اس کے مختصر فیصلے کے مقام کو ڈیٹا منتقل ہوتے وقت رکے ہوئے اپ لوڈ سے الگ کریں۔

کنکشن کھلتا ہے۔ درخواست کے ہیڈر نکل جاتے ہیں۔ فائل حرکت کرتی دکھائی نہیں دیتی۔ ایک وضاحت یہ ہے کہ کلائنٹ اپنا باڈی بھیجنے سے پہلے Expect: 100-continue کے جواب کا انتظار کر رہا ہے۔

یہ طریقہ کار وصول کنندہ کو اجازت دیتا ہے کہ ممکنہ طور پر بڑا اپ لوڈ بھیجے جانے سے پہلے درخواست کو اس کے ہیڈرز کی بنیاد پر مسترد کرے۔ عام کامیاب ترتیب یہ ہے:

request headers → 100 Continue → request body → final response

100 معلوماتی ہے: یہ کلائنٹ کو آگے بڑھنے کی اجازت دیتا ہے، لیکن اس کا مطلب یہ نہیں کہ فائل محفوظ ہو گئی یا ایپلیکیشن کا عمل کامیاب ہوا۔ HTTP 417 واپس کرنے والا Git push ایسی ہی ایک ٹھوس توقع کی ناکامی کی مثال ہے۔

معلوم کریں کہ کلائنٹ کو کون سا جواب ملا

مشاہدہکیا تحقیق کرنا ہے
100 Continueکلائنٹ باڈی کے ساتھ آگے بڑھ سکتا ہے
باڈی سے پہلے حتمی مستردعمل ہیڈر کے مرحلے میں مسترد ہوا
کوئی متوقع عبوری جواب نہیںکلائنٹ کی انتظار کی پالیسی اور اس راستے پر ہینڈلنگ

curl میں expect-continue انتظار کے لیے الگ سیٹنگ ہے۔ اگر وہ libcurl انتظار متوقع جواب کے بغیر ختم ہو جائے تو یہ باڈی بہرحال بھیج دیتا ہے؛ ختم ہونا بذات خود پوری منتقلی کی ناکامی نہیں۔ یہ سیٹنگ پوری منتقلی کے لیے دیے گئے وقت سے الگ ہے۔ بعد والا بڑھانے سے وہی ابتدائی وقفہ غیر واضح رہ سکتا ہے۔

یہ بھی پہچانیں کہ کون سی HTTP گفتگو Expect لے کر جاتی ہے۔ HTTPS منزل کی طرف عام CONNECT کے ساتھ، ویب سائٹ کا اپ لوڈ تبادلہ TLS کے اندر ہوتا ہے؛ فارورڈ پراکسی اس کے اندرونی توقع کے ہیڈر کو محض نہیں دیکھتی۔ مداخلت یا سادہ متن کی فارورڈنگ کا راستہ مختلف ہے۔

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

متعلقہ مضامین