100 Continue एक अंतरिम (सूचनात्मक) रिस्पॉन्स है। यह क्लाइंट को बताता है कि सर्वर को रिक्वेस्ट हेडर मिल गए हैं, उसने उन्हें रिजेक्ट नहीं किया है और अब वह रिक्वेस्ट बॉडी लेने के लिए तैयार है। अंतिम रिस्पॉन्स, जैसे 201 Created या 413 Content Too Large, बाद में उसी कनेक्शन पर आता है।
यह कोड बड़े अपलोड के लिए बना है। जो क्लाइंट नहीं चाहता कि मेगाबाइट्स डेटा भेजने के बाद उसे ठुकरा दिया जाए, वह अपनी रिक्वेस्ट में Expect: 100-continue जोड़ता है और थोड़ी देर इंतज़ार करता है। अगर सर्वर 100 Continue भेजता है, तो क्लाइंट बॉडी भेज देता है। अगर सर्वर 401 या 413 जैसा कोई अंतिम एरर लौटाता है, तो क्लाइंट अपलोड छोड़ सकता है। जो सर्वर इस अपेक्षा (expectation) को पूरा नहीं कर सकता, वह 417 Expectation Failed लौटा सकता है।
ब्राउज़र खुद Expect: 100-continue नहीं भेजते। इसका इस्तेमाल HTTP लाइब्रेरी, curl जैसे कमांड-लाइन टूल और फ़ाइलें अपलोड करने वाले API क्लाइंट करते हैं। क्लाइंट हमेशा इंतज़ार नहीं करते: अगर थोड़े से टाइमआउट (curl में डिफ़ॉल्ट रूप से एक सेकंड) के अंदर 100 नहीं आता, तो वे बॉडी फिर भी भेज देते हैं। सर्वर को HTTP/1.0 क्लाइंट को 1xx रिस्पॉन्स भेजने की अनुमति नहीं है।
उदाहरण रिस्पॉन्स
HTTP/1.1 100 Continue
HTTP/1.1 201 Created
Date: Fri, 06 Nov 2026 10:15:32 GMT
Location: /uploads/7f3c9a2e
Content-Length: 0SEO और रीडायरेक्ट जांच
100 कभी भी पेज स्टेटस के रूप में सर्च इंजन तक नहीं पहुंचता। इसके बाद हमेशा एक अंतिम रिस्पॉन्स आता है, और क्रॉलर व रीडायरेक्ट चेकर वही अंतिम स्टेटस दिखाते हैं। अंतरिम रिस्पॉन्स को HTTP क्लाइंट खुद ही संभाल लेता है, इसलिए TrueURL हर हॉप का अंतिम स्टेटस दिखाता है, न कि उससे पहले आया कोई 100 Continue।
आम वजहें और इस्तेमाल
- कोई API क्लाइंट या curl
Expect: 100-continueके साथ बड़ी बॉडी अपलोड करता है और सर्वर उसे लेने के लिए राज़ी हो जाता है। - कोई रिवर्स प्रॉक्सी या ऐप्लिकेशन सर्वर, ऐप्लिकेशन की ओर से इस अपेक्षा का जवाब देता है।
- अपलोड शुरू होने से पहले करीब एक सेकंड अटका रहता है: क्लाइंट ऐसे
100 Continueका इंतज़ार कर रहा है जो सर्वर कभी भेजता ही नहीं। क्लाइंट में यह अपेक्षा बंद करें या सर्वर पर इसका सपोर्ट जोड़ें।