प्रॉम्प्ट और संदर्भ
एक API गेटवे को क्लाइंट्स से HTTP/3 का उपयोग करने की आवश्यकता है, लेकिन उसे एक HTTP/1.1 अनुरोध प्राप्त होता है। समझाइए कि 426 कब लौटाना है, रिस्पॉन्स में क्या होना चाहिए, एक क्लाइंट कैसे रिकवर करता है, और प्रत्येक प्रोटोकॉल बेमेल (mismatch) को 426 क्यों नहीं बनना चाहिए।
HTTP 426 का अर्थ है कि सर्वर वर्तमान प्रोटोकॉल का उपयोग करके अनुरोध को संसाधित करने से मना करता है, लेकिन क्लाइंट द्वारा अपग्रेड करने के बाद ऐसा कर सकता है। RFC 9110, Upgrade: HTTP/3.0 के साथ इसका एक उदाहरण देता है। यह एक कार्रवाई योग्य (actionable) प्रोटोकॉल-अपग्रेड अनुरोध है, न कि कोई सामान्य पैरामीटर त्रुटि, TLS हैंडशेक विफलता, या इस बात का प्रमाण कि सर्वर संसाधन को बिल्कुल भी सर्व नहीं कर सकता है।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
साक्षात्कारकर्ता 426 के सटीक सेमेंटिक्स, Upgrade फ़ील्ड और TLS या HTTP-संस्करण नेगोशिएशन के बीच की सीमा, और कैशे, प्रॉक्सी, आइडेम्पोटेंट पुनः प्रयासों (retries), टेलीमेट्री व क्लाइंट संगतता (compatibility) के आपके प्रबंधन का परीक्षण कर रहा है। आपको 400, 421 और 505 के बीच भी अंतर स्पष्ट करना चाहिए।
स्पष्टीकरण हेतु प्रश्न
पुष्टि करें कि क्या अपग्रेड HTTP, TLS कनेक्शन, या किसी एप्लिकेशन संस्करण से संबंधित है; क्या क्लाइंट लक्षित प्रोटोकॉल स्थापित कर सकता है; क्या इस विधि (method) का पुनः प्रयास करना सुरक्षित है; क्या गेटवे के आगे कोई प्रॉक्सी मौजूद है; और क्या मूल अनुरोध को फिर से भेजा जाना चाहिए। पूछें कि क्या कुछ टेनेंट्स को पुराने प्रोटोकॉल पर ही बने रहना होगा और क्या कैनरी (canary) और रोलबैक आवश्यक हैं।
30-सेकंड का उत्तर
“मैं केवल तभी 426 लौटाऊंगा जब वर्तमान प्रोटोकॉल सर्वर को संसाधन संसाधित करने से रोकता हो, जबकि एक समर्थित लक्षित प्रोटोकॉल इसे संभाल सकता हो। रिस्पॉन्स में एक स्पष्ट Upgrade मान और पढ़ने योग्य या मशीन-पठनीय स्पष्टीकरण शामिल होना चाहिए। क्लाइंट को यह तय करने से पहले कि पुनः प्रयास करना है या नहीं, लक्षित कनेक्शन स्थापित करना होगा; वह यह मानकर नहीं चल सकता कि अनुरोध निष्पादित नहीं हुआ था। पूरी तरह से असमर्थित HTTP संस्करण 505 है, रूटिंग बेमेल 421 हो सकता है, और सामान्य सिंटैक्स त्रुटियां 400 होती हैं। गेटवे को प्रोटोकॉल, प्रॉक्सी चेन, अपग्रेड परिणामों, कैशे व्यवहार और पुनः प्रयास प्रवर्धन (retry amplification) को ट्रैक करना चाहिए।”
विस्तृत उत्तर
चरण 1: ट्रिगर स्थिति की पुष्टि करें
अनिवार्य शर्त यह है कि “वर्तमान प्रोटोकॉल अनुपयुक्त है, लेकिन अपग्रेड सफल हो सकता है।” सर्वर को एक ज्ञात लक्षित प्रोटोकॉल और एक वास्तविक अपग्रेड पथ की आवश्यकता होती है। अज्ञात क्लाइंट्स, अनुपलब्ध फ़ील्ड्स और पुराना एप्लिकेशन संस्करण स्वतः इसके योग्य नहीं बनते हैं।
चरण 2: रिस्पॉन्स को कार्रवाई योग्य (actionable) बनाएं
एक Upgrade फ़ील्ड शामिल करें जिसमें सर्वर द्वारा स्वीकार्य प्रोटोकॉल सूचीबद्ध हो, जैसे कि HTTP/3.0, साथ ही एक संक्षिप्त बॉडी या मशीन-पठनीय त्रुटि कोड दें। केवल एक अस्पष्ट “कृपया अपग्रेड करें” संदेश न लौटाएं और न ही आंतरिक टोपोलॉजी को उजागर करें।
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Content-Type: application/problem+json
{"type":"https://example.test/problems/upgrade-required","title":"Upgrade required"}चरण 3: कनेक्शन अपग्रेड को एप्लिकेशन पुनः प्रयास से अलग करें
क्लाइंट पहले लक्षित प्रोटोकॉल कनेक्शन स्थापित करता है और फिर यह तय करता है कि मूल अनुरोध को फिर से भेजना है या नहीं। कनेक्शन अपग्रेड एक ट्रांसपोर्ट या प्रोटोकॉल कार्रवाई है, न कि एप्लिकेशन फ़ील्ड में कोई परिवर्तन। गैर-आइडेम्पोटेंट POST के लिए, क्लाइंट को एक आइडेम्पोटेंसी कुंजी, निष्पादन स्थिति की जांच (execution lookup), और एक API-विशिष्ट पुनः प्रयास अनुबंध की आवश्यकता होती है।
चरण 4: TLS को सही लेयर पर रखें
426 किसी TLS हैंडशेक या प्रमाणपत्र त्रुटि की जगह नहीं लेता है। RFC 2817 में HTTP/1.1 को TLS में अपग्रेड करने की चर्चा है, लेकिन आधुनिक परिनियोजन (deployments) आमतौर पर कनेक्शन स्थापित करते समय ही TLS और HTTP संस्करणों पर नेगोशिएट करते हैं। यदि अनुरोध कभी उस चरण तक नहीं पहुंचता है जहां HTTP रिस्पॉन्स उत्पन्न किया जा सके, तो कृत्रिम 426 बनाने के बजाय हैंडशेक विफलता रिकॉर्ड करें।
चरण 5: स्टेटस-कोड की सीमाएं निर्धारित करें
400 का अर्थ अमान्य अनुरोध सिंटैक्स या सामग्री है; 421 का अर्थ है कि अनुरोध ऐसे सर्वर पर पहुंचा जो उस अनुरोध के लिए रिस्पॉन्स उत्पन्न नहीं कर सकता; 505 का अर्थ है कि सर्वर अनुरोध में उपयोग किए गए HTTP संस्करण का समर्थन नहीं करता है। 426 अपग्रेड के बाद संभावित निरंतरता का वादा करता है, इसलिए इसे किसी अनुपलब्ध लक्षित प्रोटोकॉल या अनुपलब्ध संसाधन को छिपाना नहीं चाहिए।
चरण 6: प्रॉक्सी, कैशे और पुनः प्रयास व्यवहार डिज़ाइन करें
एक प्रॉक्सी कनेक्शन समाप्त कर सकता है और दूसरा अनुरोध बना सकता है, जबकि क्लाइंट स्वचालित रूप से पुनः प्रयास कर सकते हैं। एक सुविचारित Cache-Control नीति निर्धारित करें ताकि कोई साझा कैशे माइग्रेशन त्रुटि को अनिश्चित काल तक बनाए न रखे। मूल प्रोटोकॉल, नेगोशिएटेड परिणाम, प्रॉक्सी चेन और पुनः प्रयास गणना रिकॉर्ड करें। पुनः प्रयास बजट को दर सीमाओं (rate limits) और सर्किट ब्रेकर्स के साथ संरेखित करें।
चरण 7: कैनरी और रोलबैक को सुरक्षित रखें
उन क्लाइंट्स के लिए कैनरी परिनियोजन करें जो लक्षित प्रोटोकॉल का उपयोग कर सकते हैं, सफलता दर, विलंबता (latency), त्रुटि प्रकार और डुप्लिकेट राइट्स का निरीक्षण करें, और फिर विस्तार करें। माइग्रेशन पूरा होने तक पुराने प्रोटोकॉल को बनाए रखें और क्लाइंट, टेनेंट या क्षेत्र के अनुसार रोलबैक तैयार रखें। केवल 426 की संख्या सफलता का प्रमाण नहीं है क्योंकि मध्यस्थ (intermediaries) रिस्पॉन्स को उपभोग या पुनर्लेखन (rewrite) कर सकते हैं।
चरण 8: क्लाइंट रिकवरी को सत्यापित करें
GET, आइडेम्पोटेंट PUT, गैर-आइडेम्पोटेंट POST, लंबे समय तक चलने वाले कनेक्शन, प्रॉक्सी अग्रेषण (forwarding), कैशे हिट्स, TLS विफलताएं, अज्ञात अपग्रेड मान और अनुपलब्ध लक्षित प्रोटोकॉल का परीक्षण करें। पुन: कनेक्शन, डुप्लिकेट राइट्स, प्रमाणीकरण संदर्भ, और 426, 421, 505 व हैंडशेक विफलताओं को अलग करने वाली टेलीमेट्री को सत्यापित करें।
आदर्श उत्तर
मैं पहले यह सत्यापित करूंगा कि क्या वर्तमान प्रोटोकॉल वास्तव में संसाधन को संसाधित करने से रोकता है, जबकि लक्षित प्रोटोकॉल उपलब्ध है और उसका एक परिभाषित अपग्रेड पथ है। फिर मैं आंतरिक विवरणों को लीक किए बिना, Upgrade: HTTP/3.0 और मशीन-पठनीय त्रुटि के साथ 426 लौटाऊंगा। क्लाइंट को पुनः प्रयास करने से पहले HTTP/3 स्थापित करना होगा और मेथड आइडेम्पोटेंसी, एक आइडेम्पोटेंसी कुंजी, और एक निष्पादन लुकअप का उपयोग करना होगा; वह यह अनुमान नहीं लगा सकता कि मूल राइट निष्पादित नहीं हुआ था। TLS हैंडशेक विफलताएं कनेक्शन लेयर से संबंधित हैं, पूरी तरह से असमर्थित HTTP संस्करण 505 है, रूटिंग बेमेल 421 हो सकता है, और विकृत अनुरोध 400 होते हैं। मैं क्लाइंट क्षमता के आधार पर कैनरी करूंगा, प्रोटोकॉल, प्रॉक्सी चेन, डुप्लिकेट राइट्स और सफलता दर की निगरानी करूंगा, कैशे और पुनः प्रयास सीमाएं निर्धारित करूंगा, और पुराने प्रोटोकॉल के रोलबैक पथ को सुरक्षित रखूंगा। परीक्षणों में मेथड्स, प्रॉक्सी, कैशे, लंबे कनेक्शन और एक अनुपलब्ध लक्षित प्रोटोकॉल शामिल होंगे।
सामान्य गलतियाँ
426 को एक सामान्य पुराने-क्लाइंट की त्रुटि मानना
426 एक प्रोटोकॉल अपग्रेड के बारे में है जो संभवतः उसी संसाधन को सर्व करने की अनुमति दे सकता है। एक पुराने एप्लिकेशन संस्करण, अनुपलब्ध फ़ील्ड, या अस्वीकृत अनुमति के लिए अपने स्वयं के एप्लिकेशन अनुबंध की आवश्यकता होती है।
यह मान लेना कि Upgrade फ़ील्ड अपग्रेड निष्पादित करता है
रिस्पॉन्स केवल क्लाइंट को बताता है कि आगे क्या करना है; क्लाइंट अभी भी एक उपयुक्त कनेक्शन बनाता है। सर्वर और प्रॉक्सी को लक्षित प्रोटोकॉल, प्रमाणीकरण, रूटिंग, सीमाओं और टेलीमेट्री का समर्थन करना चाहिए।
गैर-आइडेम्पोटेंट अनुरोधों को स्वचालित रूप से पुनः भेजना
426 अनुरोध-प्रसंस्करण सीमा के निकट हो सकता है। किसी आइडेम्पोटेंसी कुंजी या निष्पादन लुकअप के बिना, POST को पुनः चलाने से डुप्लिकेट साइड इफेक्ट्स हो सकते हैं।
फॉलो-अप प्रश्न और उत्तर
426 और 505 के बीच मुख्य अंतर क्या है?
426 कहता है कि एक अपग्रेड अनुरोध को सफल बना सकता है और लक्षित प्रोटोकॉल की ओर संकेत करता है। 505 कहता है कि सर्वर अनुरोध द्वारा उपयोग किए गए HTTP संस्करण का समर्थन नहीं करता है और आमतौर पर कोई अपग्रेड का वादा नहीं करता है।
यदि कोई एज प्रॉक्सी HTTP/3 को समाप्त (terminate) करता है, तो क्या ओरिजिन अभी भी 426 लौटा सकता है?
एज को अपनी सीमा पर नेगोशिएशन और रूटिंग को संभालना चाहिए और आवश्यक संदर्भ को ओरिजिन तक पहुंचाना चाहिए। यदि ओरिजिन वास्तविक क्लाइंट प्रोटोकॉल को नहीं देख सकता है, तो उसे कनेक्शन फ़ील्ड्स से इसका अनुमान नहीं लगाना चाहिए; इसके बजाय प्रॉक्सी प्रोटोकॉल और फ़ॉरवर्डिंग सेमेंटिक्स को रिकॉर्ड करें।
क्या 426 रिस्पॉन्स को कैशे किया जा सकता है?
केवल तभी जब कैशे कुंजी, क्लाइंट क्षमता और माइग्रेशन योजना स्पष्ट हो। डिफ़ॉल्ट रूप से किसी साझा कैशे द्वारा लंबे समय तक प्रोटोकॉल माइग्रेशन त्रुटि को संरक्षित करने से बचना चाहिए, जिसमें रिस्पॉन्स फ़ील्ड्स किसी भी अल्पकालिक नीति को व्यक्त करते हैं।
एक POST अनुरोध 426 से सुरक्षित रूप से कैसे रिकवर हो सकता है?
एक आइडेम्पोटेंसी कुंजी, एक निष्पादन-स्थिति लुकअप, और एक क्लाइंट पुनः प्रयास बजट का उपयोग करें। पहले लक्षित कनेक्शन स्थापित करें, फिर पुष्टि करें कि क्या मूल अनुरोध निष्पादित हुआ था। यदि इसकी पुष्टि नहीं की जा सकती है, तो आंख मूंदकर पुनः प्रयास करने के बजाय एक लंबित (pending) स्थिति की रिपोर्ट करें।
426 लौटाने के बजाय कनेक्शन को कब अस्वीकार किया जाना चाहिए?
यदि कोई HTTP रिस्पॉन्स उत्पन्न होने से पहले TLS, ALPN, या निचले स्तर का प्रोटोकॉल नेगोशिएशन विफल हो जाता है, तो कनेक्शन बंद करें और कारण रिकॉर्ड करें। 426 के लिए एक भेजने योग्य HTTP रिस्पॉन्स और एक कार्रवाई योग्य अपग्रेड सुझाव की आवश्यकता होती है।
आप कैसे साबित करते हैं कि माइग्रेशन से उपयोगकर्ताओं को कोई नुकसान नहीं हुआ?
क्लाइंट क्षमता के अनुसार कैनरी करें और 426 के बाद की सफलता, विलंबता, डुप्लिकेट राइट्स, प्रमाणीकरण विफलताओं, प्रॉक्सी वितरण और रोलबैक समय की तुलना करें। मेट्रिक्स में केवल 426 रिस्पॉन्स की गिनती करने के बजाय एज, ओरिजिन और क्लाइंट के पुनः प्रयासों को अलग-अलग वर्गीकृत किया जाना चाहिए।