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 प्रतीक्षा अपेक्षित प्रतिसादाशिवाय संपली, तरी तो बॉडी पाठवतोच; संपणे स्वतःच संपूर्ण हस्तांतरणाचे अपयश नाही. हे सेटिंग संपूर्ण हस्तांतरणासाठी दिलेल्या वेळेपेक्षा वेगळे आहे. नंतरची वेळ वाढवल्यास तीच सुरुवातीची थांब अजूनही अस्पष्ट राहू शकते.

Expect कोणत्या HTTP संवादात जातो हेही ओळखा. HTTPS गंतव्याकडे सामान्य CONNECT करताना, वेबसाइटची अपलोड देवाणघेवाण TLS च्या आत असते; फॉरवर्ड प्रॉक्सी तिचे आतील अपेक्षा हेडर सरळ तपासत नाही. अडवणूक किंवा स्पष्ट मजकुराचा फॉरवर्डिंग मार्ग वेगळा आहे.

अपेक्षा काढून टाकणे ही जाणीवपूर्वक सुसंगतता-निवड असू शकते, पण त्याचा अर्थ क्लायंट लवकर नाकारण्याची माहिती मिळण्यापूर्वी मोठा बॉडी पाठवायला लागू शकतो. त्या वर्तनाची प्रत्यक्ष गरजेशी तुलना करा. जुन्या प्रॉक्सीसाठीच्या ऐतिहासिक उपायाला प्रत्येक अपलोडमधून हेडर काढण्याची सार्वत्रिक सूचना म्हणून वर्णन करू नका.

संबंधित लेख