बैकएंड इंटरव्यू: बड़े अपलोड्स के लिए आप Expect: 100-continue का उपयोग कैसे करेंगे?

प्रॉम्प्ट और दायरा

एक क्लाइंट ऑब्जेक्ट स्टोरेज में कई सौ मेगाबाइट की फ़ाइल अपलोड करता है। सर्वर केवल अनुरोध हेडर का उपयोग करके अमान्य टोकन, कोटा या मीडिया प्रकार को अस्वीकार कर सकता है। HTTP/1.1 अपलोड हैंडशेक डिज़ाइन करें और Expect: 100-continue, 417 फ़ॉलबैक, प्रॉक्सी हॉप्स, टाइमआउट, पुनः प्रयास और मेट्रिक्स की व्याख्या करें।

यह एक बैकएंड प्रोटोकॉल और विश्वसनीयता का प्रश्न है। फ़ाइल का आकार और स्टेटस इस अभ्यास के लिए माने गए अनुमान हैं, आवृत्ति के दावे नहीं।

साक्षात्कारकर्ता क्या जांच रहा है

• क्या आप केवल-हेडर प्रवेश (admission) को बॉडी प्रोसेसिंग से अलग करते हैं।
• क्या आप 100, अंतिम प्रतिक्रिया (final response), और 417 का सटीक वर्णन करते हैं।
• क्या आप अनदेखी की गई अपेक्षाओं (ignored expectations), प्रतीक्षा टाइमआउट और कनेक्शन पुन: उपयोग को संभालते हैं।
• क्या पुनः प्रयास, इडेम्पोटेंसी, चेकसम और ऑब्जर्वेबिलिटी के स्पष्ट स्वामी (owners) हैं।

पूछने योग्य स्पष्टीकरण प्रश्न

1. क्या अपलोड इडेम्पोटेंट है, और क्या कोई अपलोड सत्र (session) या इडेम्पोटेंसी कुंजी है?
2. क्या क्लाइंट बॉडी स्रोत को रिवाइंड कर सकता है और फ़ाइल को फिर से खोल सकता है?
3. कौन से गेटवे और स्टोरेज सेवाएं सूचनात्मक प्रतिक्रियाओं (informational responses) को सुरक्षित रखती हैं?
4. क्या विफल प्रयास को Expect के बिना पुन: प्रयास किया जा सकता है, और क्या इससे डुप्लिकेट बन सकता है?
5. कौन से नियम केवल-हेडर जांच हैं, और किनके लिए पूरी बॉडी को पढ़ना आवश्यक है?

30-सेकंड का उत्तर

"क्लाइंट Expect: 100-continue के साथ हेडर भेजता है। सर्वर ऑथेंटिकेशन, लंबाई, प्रकार, कोटा और रूटिंग की जांच करता है; यह तत्काल अस्वीकृति के लिए एक अंतिम 4xx भेजता है या जब वह बॉडी के लिए तैयार होता है तो 100 Continue भेजता है। क्लाइंट केवल एक निश्चित प्रतीक्षा के साथ अंतरिम प्रतिक्रिया के बाद ही बॉडी भेजता है। 417 प्रतिक्रिया केवल तभी बिना-Expect के पुनः प्रयास को ट्रिगर कर सकती है जब बॉडी रिवाइंड करने योग्य हो और ऑपरेशन को दोबारा चलाना सुरक्षित हो। मैं समान इडेम्पोटेंसी कुंजी रखता हूँ और प्रॉक्सी व्यवहार, बचाए गए बाइट्स, 417 दर और निरस्त बॉडीज को मापता हूँ।"

चरण-दर-चरण डिज़ाइन

1. पहले हेडर भेजें

अनुरोध में ऑथेंटिकेशन, Content-Length, Content-Type, एक डाइजेस्ट, टेनेंट जानकारी, एक इडेम्पोटेंसी कुंजी और Expect: 100-continue शामिल होते हैं। बॉडी को पढ़ने से पहले, सर्वर टोकन, रूट, कोटा और स्थिर आकार सीमा की जांच कर सकता है। विनिर्देश के अनुसार निर्णय के बाद प्रतिक्रिया की आवश्यकता होती है; क्लाइंट को हमेशा के लिए प्रतीक्षा नहीं करनी चाहिए।

PUT /objects/o-123 HTTP/1.1
Host: upload.example
Authorization: Bearer ...
Content-Length: 524288000
Content-Type: application/octet-stream
Idempotency-Key: up-7f2
Expect: 100-continue

2. प्रवेश और अस्वीकृति को संभालें

प्रवेश के लिए, 100 Continue लौटाएं, फिर बॉडी प्राप्त करें। अमान्य ऑथेंटिकेशन, अत्यधिक लंबाई, या अपर्याप्त कोटा के लिए, 401, 403, 413, या 415 जैसी अंतिम स्थिति लौटाएं; क्लाइंट को वे बॉडी बाइट्स नहीं भेजने चाहिए जो उसने अभी तक नहीं भेजे हैं। प्रीफ्लाइट केवल हेडर-दृश्यमान नियमों को कवर करता है, इसलिए अंतिम परिणाम अभी भी बॉडी सत्यापन पर निर्भर करता है।

3. 417 का संकीर्ण रूप से उपयोग करें

417 Expectation Failed का अर्थ है कि सर्वर या मध्यस्थ अपेक्षा को पूरा नहीं कर सकता है। यदि ऑपरेशन इसकी अनुमति देता है, तो क्लाइंट Expect को हटा सकता है और पुनः भेज सकता है, लेकिन इसे बॉडी को रिवाइंड करने में सक्षम होना चाहिए, इडेम्पोटेंसी कुंजी को बनाए रखना चाहिए, और यह सुनिश्चित करना चाहिए कि पुराने कनेक्शन में कोई अपठित बॉडी न हो। प्रत्येक 4xx को 417 न मानें या अपरिवर्तनीय गैर-इडेम्पोटेंट कार्य को दोबारा न चलाएं।

4. प्रतीक्षा, प्रॉक्सी और कनेक्शन का ध्यान रखें

क्लाइंट 100 की प्रतीक्षा के लिए एक सीमित समय सीमा निर्धारित करता है और टाइमआउट पथ को रिकॉर्ड करता है। HTTP/1.0 मध्यस्थ Expect को अनदेखा कर सकते हैं, और एक प्रॉक्सी स्वयं 100 उत्पन्न कर सकता है। हेडर अग्रेषण, सूचनात्मक प्रतिक्रिया प्रबंधन, और क्या अंतिम अस्वीकृति कनेक्शन को बंद करती है या ड्रेन करती है, इसके लिए प्रत्येक हॉप का परीक्षण करें; अन्यथा बचे हुए बाइट्स कनेक्शन के पुन: उपयोग को दूषित कर सकते हैं।

5. पुनः प्रयासों को इडेम्पोटेंट बनाएं

पुनः प्रयास केवल तभी करें जब बॉडी स्रोत रिवाइंड करने योग्य हो और व्यावसायिक ऑपरेशन दोहराव की अनुमति देता हो। ऑब्जेक्ट निर्माण या कोटा कटौती को एक स्थिर इडेम्पोटेंसी कुंजी का उपयोग करना चाहिए ताकि प्रयास एक परिणाम से मैप हों। डिस्कनेक्ट होने के बाद, परिणाम अज्ञात हो सकता है; दूसरा ऑब्जेक्ट बनाने से पहले अपलोड सत्र या ऑब्जेक्ट स्थिति की जांच करें।

6. दोनों चरणों में सत्यापन करें

प्रीफ्लाइट जांच ऑथेंटिकेशन, टेनेंट, लंबाई, प्रकार और कोटा को कवर करती है। बॉडी प्राप्त करने के बाद, वास्तविक बाइट संख्या, डाइजेस्ट, दुर्भावनापूर्ण सामग्री और स्टोरेज नीति को सत्यापित करें। केवल Content-Length या क्लाइंट द्वारा घोषित MIME प्रकार पर भरोसा न करें। अनुरोध आईडी, प्रवेश परिणाम और प्राप्त बाइट्स को लॉग करें, टोकन या फ़ाइल सामग्री को कभी नहीं।

मॉडल उच्च-गुणवत्ता वाला उत्तर

"मैं अपलोड को हेडर निर्णय और बॉडी अंतर्ग्रहण (ingestion) में विभाजित करता हूँ। क्लाइंट ऑथेंटिकेशन, लंबाई, प्रकार, डाइजेस्ट, एक इडेम्पोटेंसी कुंजी और Expect: 100-continue भेजता है। सर्वर बॉडी से पहले सस्ती, नियतात्मक (deterministic) विफलताओं को अस्वीकार करता है; प्रवेश के बाद यह 100 भेजता है और क्लाइंट अपलोड करता है। एक 417 केवल तभी बिना-Expect के पुनः प्रयास का कारण बनता है जब समान इडेम्पोटेंसी कुंजी के साथ दोबारा चलाना सुरक्षित हो। प्रतीक्षा टाइमआउट, डिस्कनेक्ट और प्रॉक्सी व्यवहार स्थिति प्रश्नों के माध्यम से पुनर्प्राप्त होते हैं। बॉडी आकार, डाइजेस्ट और सामग्री सुरक्षा अभी भी सत्यापित की जाती है। मैं वास्तविक प्रॉक्सी में 100 लेटेंसी, 417, शुरुआती 4xx, कनेक्शन पुन: उपयोग और बचाए गए बाइट्स का परीक्षण करता हूँ।"

सामान्य गलतियाँ

• 100 को सफलता मानना → यह केवल बॉडी की अनुमति देता है → अंतिम 2xx या विफलता की प्रतीक्षा करें।
• किसी भी 4xx के बाद Expect के बिना पुनः प्रयास करना → साइड इफेक्ट्स डुप्लिकेट हो सकते हैं → केवल 417 और सुरक्षित रीप्ले के लिए फ़ॉलबैक करें।
• 100 के लिए हमेशा प्रतीक्षा करना → अनुरोध हैंग हो जाते हैं → प्रतीक्षा को सीमित और मॉनिटर करें।
• केवल हेडर की जांच करना → दूषित या दुर्भावनापूर्ण बॉडी स्टोरेज में प्रवेश कर जाती हैं → अंतर्ग्रहण के बाद भी सत्यापित करें।
• प्रॉक्सी अंतरों की अनदेखी करना → शुरुआती बॉडी या बचे हुए बाइट्स पुन: उपयोग को तोड़ते हैं → प्रत्येक हॉप का परीक्षण करें और कनेक्शन पुन: उपयोग को नियंत्रित करें।

अनुवर्ती प्रश्न और प्रतिक्रियाएं

क्या होगा यदि क्लाइंट ने 401 प्राप्त करने से पहले बॉडी बाइट्स भेज दिए हों?

सर्वर कनेक्शन बंद करने या पढ़ना जारी रखने और बॉडी को त्यागने की अपनी कनेक्शन नीति का पालन करता है। क्लाइंट भेजना बंद कर देता है और प्रयास को विफल चिह्नित करता है। पुन: उपयोग के लिए यह साबित करना आवश्यक है कि प्रोटोकॉल स्थिति फिर से संरेखित है।

हमेशा बॉडी तुरंत क्यों न भेजें?

छोटे अनुरोध हैंडशेक को उचित नहीं ठहरा सकते हैं। बड़े अनुरोधों को तब लाभ होता है जब ऑथेंटिकेशन, लंबाई या कोटा विफलताओं का जल्दी पता लगाया जा सके। अनुरोध आकार, प्रॉक्सी संगतता और कार्यान्वयन लागत के आधार पर रोल आउट करें।

क्या यह विचार अभी भी HTTP/2 या HTTP/3 के लिए महत्वपूर्ण है?

समान बाइट-स्तरीय व्यवहार न मानें। सत्यापित करें कि चुना गया क्लाइंट, गेटवे और सर्वर सूचनात्मक प्रतिक्रियाओं, प्रवाह नियंत्रण (flow control) और स्ट्रीम रद्दीकरण को कैसे संभालते हैं। शुरुआती अस्वीकृति, पुनर्प्राप्त करने योग्य अपलोड स्थिति और इडेम्पोटेंसी स्थायी लक्ष्य बने हुए हैं।