प्रॉम्प्ट और संदर्भ
एक कैश गेटवे Warning: 110 - "Response is stale" और Warning: 111 - "Revalidation failed" जोड़ता है। ब्राउज़र और डाउनस्ट्रीम सेवाएँ इन फ़ील्ड्स को सुसंगत रूप से प्रदर्शित नहीं करते हैं, और नए मानक अब इनकी अनुशंसा नहीं करते हैं। ऐतिहासिक सिमेंटिक्स, कैश-सत्यापन सीमा, प्रतिस्थापन फ़ील्ड और एक दोषरहित (lossless) माइग्रेशन की व्याख्या करें।
यह प्रश्न बैकएंड, गेटवे, CDN और प्लेटफ़ॉर्म इंटरव्यू के लिए उपयुक्त है। मुख्य बात प्रोटोकॉल मेटाडेटा, उपयोगकर्ता त्रुटियों और आंतरिक ऑब्जर्वेबिलिटी को अलग करना है, न कि एक अप्रचलित हेडर को दूसरे फ्री-फ़ॉर्म हेडर से बदलना।
इंटरव्यूअर क्या जांच रहा है
एक मजबूत उत्तर यह समझाता है कि Warning संदेश संबंधी समस्याओं का वर्णन कर सकता था और सफल सत्यापन के बाद कैश-संबंधित 1xx चेतावनियों को हटाया जा सकता था। यह यह भी नोट करता है कि यह फ़ील्ड अप्रचलित है क्योंकि इसे व्यापक रूप से जनरेट या प्रदर्शित नहीं किया गया था, जबकि इसकी जानकारी के कुछ हिस्सों का अनुमान Age जैसे फ़ील्ड्स से लगाया जा सकता है। उम्मीदवार को फ्री-फ़ॉर्म क्लाइंट अनुबंधों के बजाय Cache-Control, Date, Age, सत्यापनकर्ताओं (validators), स्थिति कोड (status codes) और संरचित मेट्रिक्स का उपयोग करना चाहिए।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
- क्या Warning ऑरिजिन, शेयर्ड कैश या एज गेटवे द्वारा जनरेट किया जाता है, और क्या इसमें कई प्रॉक्सी लेयर्स हैं?
- क्या 110 और 111 केवल डायग्नोस्टिक्स के लिए हैं, या क्या क्लाइंट इनके कारण व्यावसायिक व्यवहार बदलते हैं?
- क्या प्रतिक्रियाओं में
Date,Age,Cache-Control,ETagऔरLast-Modifiedशामिल हैं? - किन लीगेसी क्लाइंट्स का समर्थन किया जाना चाहिए, और क्या सिस्टम अस्थायी रूप से ड्यूल-राइट कर सकते हैं?
- "fresh", "stale", और "revalidation failed" की आवश्यकता किसे है: उपयोगकर्ताओं को, व्यावसायिक तर्क (business logic) को, या ऑपरेटरों को?
30-सेकंड उत्तर ढांचा
"मैं Warning को ऐतिहासिक कैश डायग्नोस्टिक्स मानूंगा, न कि एक स्थिर उपयोगकर्ता-त्रुटि अनुबंध। 110 एक पुराने (stale) रिस्पांस का वर्णन करता था और 111 एक विफल पुनर्सत्यापन (failed revalidation) का, लेकिन यह फ़ील्ड अप्रचलित है और फ्री-फ़ॉर्म टेक्स्ट के लिए अनुपयुक्त है। मैं उपभोक्ताओं और प्रॉक्सी लेयर्स की सूची बनाऊंगा, तथ्यों को Cache-Control, Date, Age, वैलिडेटर्स और स्ट्रक्चर्ड मेट्रिक्स के साथ व्यक्त करूंगा, केवल एक सीमित कम्पैटिबिलिटी विंडो के लिए ड्यूल-राइट करूंगा, और फिर क्लाइंट व्यवहार का अवलोकन करने के बाद Warning को हटा दूंगा। कैश हिट दर, stale सर्विंग, पुनर्सत्यापन विफलता और एरर-बजट मेट्रिक्स माइग्रेशन को सत्यापित करेंगे।"
चरण-दर-चरण गहन उत्तर
चरण 1: Warning की ऐतिहासिक भूमिका को पुनर्प्राप्त करना
Warning एक अनुरोध और प्रतिक्रिया हेडर था जिसमें तीन अंकों का कोड, जनरेट करने वाला एजेंट और टेक्स्ट शामिल था। कैश-संबंधित 110 और 111 एक stale रिस्पांस और विफल पुनर्सत्यापन का वर्णन करते थे; वे HTTP स्थिति कोड नहीं थे और उनका अर्थ 4xx या 5xx नहीं था। कई प्रॉक्सी फ़ील्ड जोड़ सकते थे, जिससे फ्री-फ़ॉर्म टेक्स्ट का स्रोत और विश्वास अस्थिर हो जाता था।
चरण 2: समझाएं कि माइग्रेशन की आवश्यकता क्यों है
MDN ने Warning को अप्रचलित के रूप में चिह्नित किया है क्योंकि इसे व्यापक रूप से जनरेट या प्रदर्शित नहीं किया गया था और प्रासंगिक मानक अब इस सामान्य चेतावनी तंत्र की अनुशंसा नहीं करते हैं। इस पर निर्भरता कैश डायग्नोस्टिक्स को अस्थिर टेक्स्ट से जोड़ती है और प्रॉक्सी दोहराव, पुन:क्रमण (reordering), या फ़िल्टरिंग के बारे में तर्क करना कठिन बनाती है। पहले साबित करें कि कोई भी क्लाइंट इसे व्यावसायिक सिग्नल के रूप में नहीं मानता है।
चरण 3: मानक कैश फ़ील्ड के साथ तथ्यों को व्यक्त करना
Date प्रतिक्रिया जनरेशन समय की पहचान करता है, जबकि Age एक शेयर्ड कैश में निवास समय का अनुमान लगाता है। Cache-Control ताजगी (freshness) और पुनर्सत्यापन आवश्यकताओं को परिभाषित करता है, और ETag या Last-Modified सशर्त अनुरोधों (conditional requests) का समर्थन करता है। साथ में वे कैश स्थिति का वर्णन करते हैं; एक कस्टम X-Warning स्ट्रिंग इसका विकल्प नहीं है। ऑरिजिन को Vary को भी सही ढंग से सेट करना चाहिए ताकि विभिन्न अनुरोधों के निरूपण मिश्रित न हों।
चरण 4: डायग्नोस्टिक्स को ऑब्जर्वेबिलिटी में स्थानांतरित करना
गेटवे को cache_status=stale, revalidation=failed, upstream=timeout, कैश लेयर और ट्रेस आईडी जैसी संरचित घटनाओं को रिकॉर्ड करना चाहिए। लॉग्स को संवेदनशील URL क्वेरी मानों से बचना चाहिए; मेट्रिक्स को रूट, कैश-की फ़ैमिली और अपस्ट्रीम एरर क्लास द्वारा एकत्रित किया जाना चाहिए। प्रतिक्रिया में केवल उपयोगकर्ता-प्रासंगिक स्थिति होनी चाहिए, जबकि परिचालन विवरण नियंत्रित प्रणालियों में रहता है।
चरण 5: एक कम्पैटिबिलिटी ड्यूल-राइट विंडो डिज़ाइन करना
पहले शैडो ट्रैफ़िक या किसी छोटे रूट पर Warning का उपभोग बंद करें, निर्भरताओं के लिए SDKs, स्क्रिप्ट्स और प्रॉक्सी नियमों की जांच करें। यदि कोई लीगेसी क्लाइंट मौजूद है, तो प्रतिस्थापन फ़ील्ड या अपग्रेड गाइड प्रकाशित करते समय Warning को कुछ समय के लिए बनाए रखें। प्रतिस्थापन के लिए एक स्थिर enum और संस्करणित अनुबंध की आवश्यकता होती है, न कि कॉपी किए गए मनमाने टेक्स्ट की। ड्यूल-राइट को एक स्पष्ट समाप्ति तिथि दें।
चरण 6: स्तरित कैश और सत्यापन विफलताओं को संभालना
एक विफल पुनर्सत्यापन का मतलब अनिवार्य रूप से यह नहीं है कि ऑरिजिन डाउन है; यह टाइमआउट, अस्वीकृत सशर्त अनुरोध या अपस्ट्रीम 5xx हो सकता है। तय करें कि stale सामग्री प्रस्तुत करनी है, त्रुटि लौटानी है, या stale-if-error नीति लागू करनी है, और कारण रिकॉर्ड करें। Warning को हटाने से stale सर्विंग छिपनी नहीं चाहिए या अनंत पुनरावृत्तियां (retries) नहीं बननी चाहिए।
चरण 7: 103 Early Hints को कैश चेतावनियों से अलग करना
103 Early Hints अंतिम प्रतिक्रिया से पहले आता है और संभावित संसाधनों का संकेत देता है, आमतौर पर प्रीकनेक्ट या प्रीलोड के लिए Link के माध्यम से। यह कैश ताजगी या पुनर्सत्यापन विफलता की रिपोर्ट नहीं करता है और Age या Cache-Control को प्रतिस्थापित नहीं करता है। प्रत्येक संकेत को Warning के रूप में मानने के बजाय प्रत्येक फ़ील्ड के समय, उपभोक्ता और विफलता सिमेंटिक्स को स्पष्ट करें।
चरण 8: इसे चरणों में हटाएं और सत्यापित करें
माइग्रेशन से पहले और बाद में Warning रीड्स, कैश हिट दर, stale-सर्विंग अनुपात, सशर्त-अनुरोध सफलता, ऑरिजिन त्रुटियों, P95 लेटेंसी और क्लाइंट त्रुटियों की तुलना करें। एक कैश लेयर में जेनरेशन को अक्षम करें, पूरी श्रृंखला में विस्तार करें, फिर लीगेसी क्लाइंट के साफ होने के बाद कोड, दस्तावेज़ और अलर्ट हटा दें। रोलबैक स्विच को केवल कम्पैटिबिलिटी आउटपुट को पुनर्स्थापित करना चाहिए, कभी भी Warning पर व्यावसायिक निर्भरता को बहाल नहीं करना चाहिए।
ट्रेड-ऑफ़ और सीमाएँ
Warning को बनाए रखने की अल्पकालिक अनुकूलता लागत कम है लेकिन यह एक अस्थिर अनुबंध और अस्पष्ट समस्या निवारण को लम्बा खींचता है। तत्काल निष्कासन प्रोटोकॉल शोर को कम करता है लेकिन लीगेसी स्क्रिप्ट को तोड़ सकता है। सबसे सुरक्षित मार्ग वास्तविक निर्भरताओं का निरीक्षण करता है, फिर आवश्यकता को मानक कैश फ़ील्ड और संरचित ऑब्जर्वेबिलिटी में स्थानांतरित करता है।
Age को ऑरिजिन जनरेशन समय के रूप में या Cache-Control: no-cache को "कैश न करें" के रूप में व्याख्या न करें; इसके पुन: उपयोग से पहले पुनर्सत्यापन की आवश्यकता होती है। कैश नीति, सत्यापनकर्ता और त्रुटि प्रतिक्रियाओं को व्यवसाय की स्वीकार्य ताजगी विंडो के साथ डिज़ाइन किया जाना चाहिए।
रोलआउट योजना और साक्ष्य
पहले सप्ताह में, रूट और कैश लेयर द्वारा एक बेसलाइन स्थापित करते हुए, एज, शेयर्ड कैश और क्लाइंट से Warning रीड पाथ निर्यात करें। इसके बाद, महत्वपूर्ण निर्भरता के बिना एक रूट पर संरचित मेट्रिक्स को ड्यूल-राइट करें और Age, सशर्त अनुरोधों और त्रुटि दरों की तुलना करें। अंत में, एक-क्लिक कम्पैटिबिलिटी-आउटपुट स्विच को बनाए रखते हुए लेयर दर लेयर Warning को अक्षम करें।
स्वीकृति के लिए आवश्यक है कि कोई भी प्रोडक्शन क्लाइंट Warning को न पढ़े; कैश-हिट और पुनर्सत्यापन सफलता में गिरावट न आए; stale-if-error घटनाएँ व्याख्या योग्य हों; लॉग और मेट्रिक्स ट्रेस आईडी द्वारा सहसंबंधित हों; और दस्तावेज़, SDKs और अलर्ट अपडेट किए गए हों।
सामान्य गलतियाँ और फॉलो-अप
110 को 4xx या 5xx के रूप में मानना
110 एक ऐतिहासिक Warning कोड है, प्रतिक्रिया स्थिति (response status) नहीं। व्यावसायिक त्रुटियां स्थिति और प्रतिक्रिया अनुबंधों से संबंधित हैं; कैश डायग्नोस्टिक्स मेट्रिक्स से संबंधित हैं।
X-Warning के साथ समस्या को फिर से बनाना
फ्री टेक्स्ट, प्रॉक्सी जोड़ना और संस्करण कम्पैटिबिलिटी अनिश्चित बनी हुई है। यदि कम्पैटिबिलिटी की आवश्यकता है, तो एक स्थिर enum, संस्करण और स्पष्ट उपभोक्ताओं का उपयोग करें।
ऑब्जर्वेबिलिटी के बिना हेडर को हटाना
फ़ील्ड को हटाने से stale सर्विंग या विफल पुनर्सत्यापन ठीक नहीं होता है। बाहरी हेडर को हटाने से पहले कैश-स्टेट मेट्रिक्स, ट्रेसिंग और अलर्ट स्थापित करें।
103 Early Hints को कैश चेतावनी के रूप में मानना
103 का समय और उद्देश्य संसाधन संकेत हैं; यह ताजगी या पुनर्सत्यापन विफलता को व्यक्त नहीं कर सकता है। अलग-अलग फ़ील्ड और प्रसंस्करण पथ रखें।
आप कैसे साबित करते हैं कि इसे हटाया जा सकता है?
क्लाइंट रीड्स, प्रॉक्सी कॉन्फ़िगरेशन, त्रुटि दरों और कैश मेट्रिक्स का निरीक्षण करें; एक सीमित ड्यूल-राइट विंडो चलाएं और सिंगल-लेयर कैनरी के बाद विस्तार करें। निर्भरता साक्ष्य के बिना विश्व स्तर पर न हटाएं।