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 के भीतर होती है; फ़ॉरवर्ड प्रॉक्सी उसके भीतरी अपेक्षा हेडर का सीधे निरीक्षण नहीं करता। इंटरसेप्शन या स्पष्ट-पाठ अग्रेषण का पथ अलग है।

अपेक्षा हटाना जानबूझकर संगतता का चयन हो सकता है, पर इसका अर्थ है कि क्लाइंट शीघ्र अस्वीकृति की जानकारी मिलने से पहले बड़ी बॉडी भेजना शुरू कर सकता है। उस व्यवहार की तुलना वास्तविक आवश्यकता से करें। पुराने प्रॉक्सी के लिए किए गए ऐतिहासिक उपाय को हर अपलोड से हेडर हटाने का सार्वभौमिक निर्देश न बनाएँ।

संबंधित लेख