प्रॉम्प्ट और संदर्भ
यह बैकएंड प्रश्न HTTP आंशिक प्रतिक्रियाओं (partial responses), ऑब्जेक्ट-स्टोर रीड्स और डाउनलोड स्टेट मशीन का परीक्षण करता है। चुनौती केवल स्टोरेज को हेडर अग्रेषित (forward) करने की नहीं है; बल्कि विफलता और पुनः प्रयास (retry) के दौरान रेंज, एंटिटी वर्ज़न, एन्कोडिंग, अनुमतियों और समवर्ती (concurrent) सेगमेंट को सुसंगत बनाए रखने की है।
इंटरव्यूअर क्या मूल्यांकन करता है
- क्या आप एक बाइट रेंज को पार्स करते हैं और 206, Content-Range, Content-Length, और Accept-Ranges को सही ढंग से बनाते हैं।
- क्या If-Range के साथ ETag या Last-Modified किसी क्लाइंट को अलग-अलग फ़ाइल वर्ज़न को जोड़ने (join करने) से रोकता है।
- क्या अमान्य रेंज, समाप्त हो चुके हस्ताक्षर (expired signatures), हटाए गए ऑब्जेक्ट, रेट लिमिट और मल्टी-रेंज की लागत को संभाला जाता है।
- क्या इंटीग्रिटी, ऑब्ज़र्वेबिलिटी और ऑथराइज़ेशन एंडपॉइंट को एक मनमाना ऑब्जेक्ट रीडर बनने से रोकते हैं।
स्पष्टीकरण के लिए पूछे जाने वाले प्रश्न
पुष्टि करें कि क्या ऑब्जेक्ट सार्वजनिक हैं, अधिकतम आकार क्या है, क्या मल्टी-रेंज प्रतिक्रियाओं की आवश्यकता है, क्या स्टोरेज नेटिव रेंज का समर्थन करता है, क्या कम्प्रेशन की अनुमति है, और क्या क्लाइंट ETag को बनाए रखता है (persist करता है)। URL के लाइफ़टाइम, सेगमेंट कॉनकरेंसी, इंटीग्रिटी एल्गोरिदम और रिसोर्स वर्ज़न बदलने पर उत्पाद के व्यवहार के बारे में पूछें।
30-सेकंड उत्तर रूपरेखा
मैं अनुरोध को ऑथराइज़ करूँगा और एक ऑब्जेक्ट वर्ज़न को पिन करूँगा, फिर आकार, ETag और मीडिया मेटाडेटा को पढ़ूँगा। कोई Range न होने पर 200 लौटाया जाता है; एक संतुष्ट होने योग्य (satisfiable) रेंज पर सटीक Content-Range के साथ 206 लौटाया जाता है; विकृत या असंतुष्ट रेंज पर वर्तमान लंबाई के साथ 416 लौटाया जाता है। If-Range बेमेल होने पर वर्तमान वर्ज़न के लिए पूरी प्रतिक्रिया दी जाती है ताकि क्लाइंट पुनः आरंभ कर सके। प्रत्येक सेगमेंट रेट- और कॉनकरेंसी-सीमित होता है, और प्रतिक्रिया व अंतिम फ़ाइल दोनों को वर्ज़न और चेकसम के विरुद्ध जाँचा जाता है।
चरण-दर-चरण विस्तृत विश्लेषण
1. रिप्रजेंटेशन और ऑथराइज़ेशन सीमा को पिन करें
उपयोगकर्ता, टेनेंट और ऑब्जेक्ट आईडी द्वारा ऑथराइज़ करें; कभी भी किसी मनमाने क्लाइंट पथ को सीधे स्टोरेज कुंजी पर मैप न करें। ऑब्जेक्ट मेटाडेटा पढ़ें और एक वर्ज़न पहचानकर्ता, कुल बाइट्स, Content-Type, Content-Encoding और ETag को पिन करें। यदि ऑब्जेक्ट बदलते हैं, तो इम्यूटेबल या वर्ज़न वाले स्टोरेज का उपयोग करें ताकि एक डाउनलोड के दौरान मेटाडेटा और बाइट्स में अंतर (drift) न आए।
2. रेंज पार्स करें और प्रतिक्रियाएँ बनाएँ
एक bytes=start-end, bytes=start-, या bytes=-suffix रेंज का समर्थन करें, पूर्णांकों (integers), ओवरफ़्लो और कुल लंबाई को मान्य करें। एक संतुष्ट होने योग्य रेंज को रिप्रजेंटेशन के अनुसार क्लैंप करने के बाद, 206, Content-Range और सटीक लंबाई लौटाएँ। बिना Range के 200 लौटाएँ। यदि कोई भी रेंज संतुष्ट होने योग्य नहीं है, तो Content-Range: bytes */total के साथ 416 लौटाएँ। मल्टी-रेंज अनुरोधों के लिए एक स्पष्ट विकल्प की आवश्यकता होती है: अस्वीकार करें, सीमित अनुरोधों में विभाजित करें, या multipart लागू करें; कभी भी चुपचाप पहला भाग न लौटाएँ।
3. If-Range और सामग्री कोडिंग को संभालें
If-Range में एक स्ट्रॉन्ग ETag या दिनांक का सम्मान केवल तभी करें जब वह अभी भी चयनित रिप्रजेंटेशन से मेल खाता हो; अन्यथा Range को अनदेखा करें और वर्तमान पूर्ण रिप्रजेंटेशन भेजें। रेंज वास्तव में स्थानांतरित किए गए रिप्रजेंटेशन के बाइट्स को संदर्भित करती हैं। कंप्रेस्ड बाइट्स को स्लाइस न करें और क्लाइंट से उन्हें इस तरह जोड़ने के लिए न कहें जैसे कि वे अनकंप्रेस्ड फ़ाइल हों। या तो डायनेमिक कम्प्रेशन को अक्षम करें या प्रत्येक एन्कोडिंग को एक स्वतंत्र वर्ज़न और चेकसम दें।
4. कॉनकरेंसी, लागत और रिकवरी को सीमित करें
प्रति उपयोगकर्ता, टेनेंट और ऑब्जेक्ट सेगमेंट को सीमित करें, साथ ही कुल बैंडविड्थ और न्यूनतम रेंज आकार को भी सीमित करें, ताकि कई छोटे अनुरोध स्टोरेज लागत को न बढ़ाएँ। विफल सेगमेंट को केवल उसी वर्ज़न और रेंज के साथ पुनः प्रयास करें। यदि कोई हस्ताक्षरित URL समाप्त हो जाता है, तो वर्ज़न बदले बिना एक नया URL जारी करें। ऑब्जेक्ट हटाने या अनुमति परिवर्तन बाद के सेगमेंट को रोक देते हैं, और क्लाइंट अधूरी फ़ाइल को चुपचाप जोड़ने के बजाय उसे डिस्कार्ड कर देता है।
5. इंटीग्रिटी सत्यापित करें और व्यवहार का निरीक्षण करें
डाउनलोड के बाद, ऑब्जेक्ट वर्ज़न, कुल लंबाई और चेकसम सत्यापित करें; उच्च जोखिम वाले डेटा के लिए, जोड़ने से पहले प्रत्येक सेगमेंट को सत्यापित करें। डाउनलोड क्रेडेंशियल्स को लॉग किए बिना सामान्यीकृत (normalized) रेंज, वर्ज़न, स्थिति, बाइट्स, स्टोरेज लेटेंसी, कैश हिट और पुनः प्रयास गणना को लॉग करें। खाली रेंज, प्रत्यय (suffixes), ओवरफ़्लो, ऑब्जेक्ट अपडेट, समवर्ती पुनः प्रयास, ऑफ़लाइन रिज्यूम और प्रत्येक Content-Encoding का परीक्षण करें ताकि यह साबित हो सके कि 206 कभी भी गलत वर्ज़न प्रदान नहीं करता है।
मजबूत उत्तर का उदाहरण
ऑथराइज़ेशन के बाद मैं एक इम्यूटेबल ऑब्जेक्ट वर्ज़न को पिन करता हूँ और इसके आकार, ETag, प्रकार और एन्कोडिंग को प्रदर्शित करता हूँ। एक संतुष्ट होने योग्य एकल bytes रेंज Content-Range और Content-Length के साथ 206 लौटाती है; कोई रेंज न होने पर 200 लौटता है; असंतुष्ट होने पर bytes */total के साथ 416 लौटता है। If-Range बेमेल होने पर Range को अनदेखा किया जाता है और वर्तमान पूर्ण वर्ज़न भेजा जाता है, जिससे मिश्रित फ़ाइलों को रोका जा सकता है। प्रति-उपयोगकर्ता और प्रति-ऑब्जेक्ट कॉनकरेंसी, रेट और न्यूनतम-रेंज सीमाएँ लागत को नियंत्रित करती हैं, और पुनः प्रयास समान वर्ज़न बनाए रखते हैं। क्लाइंट लंबाई, वर्ज़न और चेकसम की पुष्टि करता है; सर्वर रेंज, स्थिति, स्टोरेज लेटेंसी और पुनः प्रयासों का निरीक्षण करता है।
सामान्य गलतियाँ
- ऑथराइज़ेशन, ऑब्जेक्ट वर्ज़न, या पूर्णांक ओवरफ़्लो की जाँच किए बिना Range को अग्रेषित करना।
- असंतुष्ट होने योग्य रेंज के लिए 416 के बजाय 200 या खाली बॉडी लौटाना।
- If-Range की अनदेखी करना और अपडेट को मिश्रित-वर्ज़न वाली फ़ाइल बनाने की अनुमति देना।
- कंप्रेस्ड बाइट्स पर रेंज निर्देशांक लागू करना जिसे क्लाइंट बाद में अनकंप्रेस्ड के रूप में ट्रीट करता है।
- असीमित छोटे सेगमेंट और कॉनकरेंसी की अनुमति देना, जिससे एक ही डाउनलोड स्टोरेज पर भारी लोड (storm) बन जाए।
- कुल लंबाई, ETag और अंतिम चेकसम के बजाय केवल स्टेटस कोड की जाँच करना।
फॉलो-अप प्रश्न और उत्तर
हमेशा 206 क्यों नहीं लौटाते?
बिना Range के क्लाइंट ने पूर्ण रिप्रजेंटेशन का अनुरोध किया था, इसलिए 200 सही है। Range के साथ भी, सर्वर को संतुष्टि (satisfiability) की जाँच करनी चाहिए; 416 क्लाइंट को वर्तमान लंबाई बताता है ताकि वह अनुरोध को सही कर सके।
If-Range, If-Match से किस प्रकार भिन्न है?
If-Range यह तय करता है कि क्या आंशिक स्थानांतरण जारी रह सकता है: एक मिलान पर 206 मिलता है और बेमेल होने पर पूर्ण रिप्रजेंटेशन मिलता है। If-Match एक लक्षित ऑपरेशन करने के लिए एक पूर्व शर्त (precondition) है, इसलिए इसकी विफलता का एक अलग अर्थ होता है।
मल्टी-रेंज अनुरोधों के साथ आपको क्या करना चाहिए?
पहले पुष्टि करें कि क्या क्लाइंट और स्टोरेज को उनकी आवश्यकता है। सीमित अनुरोधों में विभाजित करें या multipart/byteranges लागू करें; यदि लागत उचित नहीं है, तो पहली रेंज लौटाकर अस्पष्टता पैदा करने के बजाय स्पष्ट रूप से अस्वीकार करें।
आप हस्ताक्षरित डाउनलोड लिंक के दुरुपयोग को कैसे रोकते हैं?
उपयोगकर्ता, टेनेंट, ऑब्जेक्ट, वर्ज़न और अनुमति से बंधे अल्पकालिक हस्ताक्षरों का उपयोग करें। सर्वर-साइड सीमाओं को पुनः जाँचें और कॉनकरेंसी, रेट, रेंज गणना और कुल बाइट्स को सीमित करें। निरस्त पहुँच (revoked access) या विलोपन को बाद के रेंज अनुरोधों को अमान्य करना होगा।