बैकएंड इंटरव्यू: किसी API को 421 Misdirected Request कब लौटाना चाहिए?

1. प्रश्न और संदर्भ

एक HTTPS मल्टी-टेनेंट API कई डोमेन में HTTP/2 कनेक्शनों का पुनर्चक्रण (reuse) करता है। कुछ अनुरोधों में रुक-रुक कर 421 प्राप्त होता है, और टीम इसे एप्लिकेशन कंट्रोलर में 503 के रूप में फिर से लिखना (rewrite) चाहती है। 421 के सेमांटिक्स का मूल्यांकन करें, SNI बनाम Host की व्याख्या करें, और गेटवे, ओरिजिन, क्लाइंट और ऑब्जर्वेबिलिटी योजना डिज़ाइन करें। मान लें कि अनुरोध CDN, रिवर्स प्रॉक्सी और सर्विस मेश से होकर गुजर सकते हैं।

2. इंटरव्यूअर क्या परख रहा है

• क्या आप जानते हैं कि 421 का अर्थ है कि अनुरोध ऐसे ओरिजिन पर पहुंचा जो टारगेट URI के लिए आधिकारिक प्रतिक्रिया (authoritative response) देने में असमर्थ या अनिच्छुक है।
• क्या आप कनेक्शन पुनर्चक्रण, TLS SNI, अनुरोध Host, स्कीम और अथॉरिटी को एक डायग्नोस्टिक श्रृंखला में जोड़ सकते हैं।
• क्या आप समझते हैं कि किसी प्रॉक्सी को अपने स्वयं के रूटिंग निर्णय से 421 नहीं बनाना चाहिए और क्लाइंट को केवल एक नए कनेक्शन पर ही पुनः प्रयास करना चाहिए।
• क्या आप केवल स्टेटस कोड बदलने के बजाय 421 को अपस्ट्रीम विफलता, 404, 503 और प्रमाणपत्र कॉन्फ़िगरेशन त्रुटियों से अलग कर सकते हैं।

3. उत्तर देने से पहले स्पष्टीकरण प्रश्न

1. क्या 421 ओरिजिन, गेटवे, CDN या एप्लिकेशन द्वारा जनरेट किया गया है?
2. क्या अनुरोध HTTP/2 या HTTP/3 का उपयोग कर रहा है, और क्या एक कनेक्शन कई अथॉरिटीज़ को ले जा सकता है?
3. अंतिम हॉप पर TLS SNI, HTTP Host और चयनित वर्चुअल होस्ट क्या हैं?
4. क्या क्लाइंट टारगेट डोमेन के लिए एक नया कनेक्शन खोल सकता है, और क्या मेथड इडेम्पोटेंट (idempotent) है या पहले से ही साइड-इफेक्टिंग है?

4. 30-सेकंड का उत्तर ढांचा

421 का अर्थ है कि ओरिजिन मानता है कि अनुरोध गलत कनेक्शन या वर्चुअल होस्ट पर निर्देशित किया गया था, जैसे कि कनेक्शन प्रमाणपत्र और टारगेट अथॉरिटी का एक असंगत संयोजन। प्रतिक्रिया बदलने से पहले SNI, Host, स्कीम, अथॉरिटी, कनेक्शन पूलिंग और ओरिजिन रूटिंग का निदान करें; इसे 503 के रूप में दोबारा न लिखें। एक ओरिजिन 421 भेज सकता है, जबकि एक प्रॉक्सी को इसे अपने स्वयं के रूटिंग निर्णय से बनाने के बजाय अग्रेषित (forward) करना चाहिए। क्लाइंट मेथड इडेम्पोटेंसी, अनुरोध-बॉडी रीप्ले और बैकऑफ़ के अधीन, एक नए कनेक्शन पर पुनः प्रयास कर सकता है। लॉग में कनेक्शन ID, SNI, अथॉरिटी, रूट और पुनः प्रयास के परिणाम को सहसंबंधित (correlate) करें।

5. चरण-दर-चरण विस्तृत उत्तर

चरण 1: ज़िम्मेदारी की सीमा को परिभाषित करें

RFC 9110 421 को ओरिजिन अस्वीकृति के रूप में परिभाषित करता है क्योंकि टारगेट URI गलत निर्देशित प्रतीत होता है। इसका कारण ओरिजिन कॉन्फ़िगरेशन बेमेल या ऐसा अनुरोध हो सकता है जो वर्तमान कनेक्शन संदर्भ में फिट नहीं बैठता है। एप्लिकेशन को मनमाने अपस्ट्रीम टाइमआउट, DNS त्रुटियों या समाप्त हो चुके प्रमाणपत्रों को 421 पर मैप नहीं करना चाहिए; उन स्थितियों को अपने स्वयं के सेमांटिक्स की आवश्यकता होती है।

चरण 2: कनेक्शन संदर्भ का पुनर्निर्माण करें

TLS हैंडशेक के दौरान, SNI एक प्रमाणपत्र और वर्चुअल होस्ट का चयन करता है। एन्क्रिप्शन स्थापित होने के बाद, अनुरोध Host या अथॉरिटी टारगेट का चयन करती है। HTTP/2 एक कनेक्शन पर कई अनुरोध ले जा सकता है, लेकिन पुनर्चक्रण केवल तभी सुरक्षित होता है जब प्रमाणपत्र, प्रोटोकॉल और सर्वर कॉन्फ़िगरेशन इसकी अनुमति देते हैं। SNI, Host, स्कीम, अथॉरिटी, ALPN, कनेक्शन प्रारंभ समय और चयनित बैकएंड को रिकॉर्ड करें, फिर तुलना करें कि कनेक्शन का स्वामी कौन है और अनुरोध कहां जा रहा है।

TLS SNI: api-a.example
HTTP authority: api-b.example
ALPN: h2
selected virtual host: api-a.example
result: 421 from origin

चरण 3: प्रॉक्सी, CDN और सर्विस मेश को संभालें

एक एज प्रॉक्सी को मूल अथॉरिटी, TLS-समाप्ति विवरण और अपस्ट्रीम कनेक्शन स्थिति को बनाए रखना चाहिए, जबकि एक असंगत अपस्ट्रीम कनेक्शन पर क्रॉस-टेनेंट पुनर्चक्रण को रोकना चाहिए। यह ओरिजिन 421 को अग्रेषित कर सकता है, लेकिन इसे केवल इसलिए 421 उत्पन्न नहीं करना चाहिए क्योंकि इसका अपना रूट विफल हो गया; प्रॉक्सी के 502, 503 या रूटिंग-त्रुटि अनुबंध का उपयोग करें। सर्विस-मेश पूल कुंजी में वे फ़ील्ड शामिल होने चाहिए जो केवल IP और पोर्ट द्वारा पूलिंग करने के बजाय प्रमाणपत्र और वर्चुअल-होस्ट चयन को प्रभावित करते हैं।

चरण 4: क्लाइंट पुनः प्रयास डिज़ाइन करें

विनिर्देश क्लाइंट को टारगेट ओरिजिन के लिए एक नए कनेक्शन सहित एक अलग कनेक्शन पर 421 का पुनः प्रयास करने की अनुमति देता है। पुनः प्रयास करने से पहले, मेथड इडेम्पोटेंसी, अनुरोध-बॉडी रीप्लेएबिलिटी, टोकन वैधता, और क्या आंशिक प्रतिक्रिया या साइड इफेक्ट पहले ही हो चुका है, इसकी जांच करें। POST या अन्य साइड-इफेक्टिंग विधियों के लिए, इडेम्पोटेंसी कुंजी का उपयोग करें या पुष्टि करें कि पुनः प्रयास करने से पहले निष्पादन नहीं हुआ था। प्रयासों को सीमित करें और कारण रिकॉर्ड करें; एक निश्चित लूप को कॉन्फ़िगरेशन त्रुटि नहीं छिपानी चाहिए।

चरण 5: निरीक्षण करें, ठीक करें और रिग्रेशन-परीक्षण करें

केवल वैश्विक गणना देखने के बजाय 421 को SNI, अथॉरिटी, वर्चुअल होस्ट, प्रोटोकॉल संस्करण और एज नोड द्वारा विभाजित करें। एक संशोधित (redacted) कनेक्शन ID, रूट निर्णय, प्रमाणपत्र फ़िंगरप्रिंट, ओरिजिन प्रतिक्रिया, और क्या क्लाइंट ने नया कनेक्शन खोला, इसे सुरक्षित रखें। सुधार के बाद, तीन पथों का परीक्षण करें: वैध पुनर्चक्रण को 421 नहीं लौटाना चाहिए; एक असंगत कनेक्शन को लगातार 421 लौटाना चाहिए; नए कनेक्शन पर पुनः प्रयास को लक्षित सेवा की अंतिम प्रतिक्रिया तक पहुंचना चाहिए।

6. एक उच्च-गुणवत्ता वाले उत्तर का उदाहरण

मैं 421 को एक कनेक्शन-संदर्भ या ओरिजिन-अथॉरिटी बेमेल मानूंगा, न कि एक सामान्य क्षणिक आउटेज। पहले TLS SNI, HTTP अथॉरिटी, प्रमाणपत्र, ALPN, कनेक्शन पूल और वर्चुअल-होस्ट रूटिंग को सहसंबंधित करें ताकि यह पुष्टि हो सके कि क्या अनुरोध ने एक असंगत कनेक्शन का पुनर्चक्रण किया था। ओरिजिन 421 लौटा सकता है, जबकि एक प्रॉक्सी को इसे बनाने के बजाय अग्रेषित करना चाहिए। एक क्लाइंट टारगेट ओरिजिन के लिए एक नया कनेक्शन खोल सकता है और केवल इडेम्पोटेंसी, बॉडी रीप्ले और इडेम्पोटेंसी कुंजियों की जांच के बाद ही पुनः प्रयास कर सकता है। डोमेन, प्रोटोकॉल, नोड और पूल द्वारा कोड को मापें, फिर पुनर्चक्रण और नए-कनेक्शन दोनों रिग्रेशन परीक्षणों के साथ सुधार को साबित करें।

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

• प्रत्येक 421 को 503 के रूप में दोबारा लिखना → कनेक्शन-संदर्भ साक्ष्य खो देता है → 421 को सुरक्षित रखें और गेटवे पर SNI और अथॉरिटी को लॉग करें।
• Host की जाँच करना लेकिन SNI की नहीं → प्रमाणपत्र और वर्चुअल-होस्ट पुनर्चक्रण छूट जाता है → TLS और HTTP दोनों लक्ष्यों को रिकॉर्ड करें।
• किसी प्रॉक्सी को 421 उत्पन्न करने देना → स्थिति-कोड ज़िम्मेदारी सीमा का उल्लंघन करता है → ओरिजिन 421 को अग्रेषित करें और प्रॉक्सी रूटिंग विफलताओं के लिए एक स्पष्ट 5xx अनुबंध का उपयोग करें।
• POST को बिना शर्त पुनः प्रयास करना → डुप्लिकेट राइट्स हो सकते हैं → इडेम्पोटेंसी कुंजी का उपयोग करें या सीमित पुनः प्रयास से पहले पुष्टि करें कि कोई निष्पादन नहीं हुआ।
• केवल एक डोमेन और एक कनेक्शन का परीक्षण करना → HTTP/2 पुनर्चक्रण छूट जाता है → क्रॉस-डोमेन पुनर्चक्रण, असंगत पुनर्चक्रण और नए-कनेक्शन परीक्षण शामिल करें।

8. फॉलो-अप और उत्तर

421 503 से किस प्रकार भिन्न है?

421 अनुरोध और वर्तमान कनेक्शन या ओरिजिन अथॉरिटी के बीच बेमेल की ओर इशारा करता है; एक टारगेट-विशिष्ट नया कनेक्शन इसे ठीक कर सकता है। 503 का अर्थ है कि सेवा अस्थायी रूप से अनुरोध को संभालने में असमर्थ है, अक्सर क्षमता, रखरखाव या किसी निर्भरता के कारण। उनके सुधार, पुनः प्रयास नियम और अलर्ट आयाम भिन्न होते हैं।

क्या कोई क्लाइंट पुराने कनेक्शन पर 421 का पुनः प्रयास कर सकता है?

उसे ऐसे कनेक्शन का उपयोग जारी नहीं रखना चाहिए जिसे अनुपयुक्त माना गया था। टारगेट ओरिजिन के लिए एक नया कनेक्शन खोलें और बैकऑफ़, बॉडी रीप्ले और प्रमाणीकरण स्थिति का सम्मान करते हुए TLS और प्रोटोकॉल पर फिर से बातचीत (renegotiate) करें।

क्या प्रॉक्सी 421 लौटा सकता है जब Host और SNI भिन्न हों?

केवल प्रॉक्सी के अपने अनुमान से नहीं। इसे अपने रूटिंग-त्रुटि अनुबंध का पालन करना चाहिए या निर्णय लेने के लिए अनुरोध को ओरिजिन पर अग्रेषित करना चाहिए। यदि यह ओरिजिन 421 को अग्रेषित करता है, तो निदान के लिए स्रोत जानकारी को सुरक्षित रखें।

आप कैसे साबित करेंगे कि पूल फिक्स ने प्रदर्शन को नुकसान नहीं पहुंचाया?

वैध पुनर्चक्रण, अथॉरिटी-कुंजी वाले पूल और अस्वीकृत असंगत पुनर्चक्रण को अलग-अलग मापें। 421 दर, हैंडशेक गणना, टेल लेटेंसी, कनेक्शन गणना और CPU की तुलना करें। लक्ष्य अतिरिक्त हैंडशेक लागत को बजट के भीतर रखते हुए गलत पुनर्चक्रण को हटाना है।