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 भित्र हुन्छ; फर्वार्ड प्रोक्सीले यसको भित्री अपेक्षा हेडर सिधै जाँच्दैन। अवरोध वा सादा पाठ फर्वार्डिङ मार्ग फरक हुन्छ।

अपेक्षा हटाउनु जानाजानको अनुकूलता छनोट हुन सक्छ, तर यसको अर्थ ग्राहकले चाँडो अस्वीकृतिको जानकारी पाउनुअघि ठूलो बडी पठाउन थाल्न सक्छ। त्यो व्यवहारलाई वास्तविक आवश्यकतासँग तुलना गर्नुहोस्। पुरानो प्रोक्सीका लागि ऐतिहासिक समाधानलाई हरेक अपलोडबाट हेडर हटाउने सार्वभौमिक निर्देशनका रूपमा वर्णन नगर्नुहोस्।

सम्बन्धित लेखहरू