प्रश्न और उपयुक्त परिदृश्य
आप एक ऐसे API गेटवे के स्वामी हैं जो दुर्भावनापूर्ण अटैचमेंट को फ़िल्टर कर सकता है, निजी फ़ील्ड हटा सकता है, या रिस्पॉन्स को ट्रांसकोड कर सकता है। ओरिजिन अनुरोध सफल होता है, लेकिन डाउनस्ट्रीम रिप्रेजेंटेशन अब ओरिजिन के बाइट्स जैसा नहीं रहता है। बताएं कि 203 कब लौटाना है, वैलिडेटर्स को कैसे संभालना है, और क्लाइंट्स को ट्रांसफॉर्म किए गए डेटा को आधिकारिक ओरिजिन डेटा मानने से कैसे रोकना है।
HTTP 203 एक सफल रिस्पॉन्स है जो यह दर्शाता है कि एक ट्रांसफॉर्मिंग प्रॉक्सी ने ओरिजिन के 200 रिस्पॉन्स से हेडर या कंटेंट को बदल दिया है। यह "सफल, लेकिन रूपांतरित" के लिए एक प्रोटोकॉल सिग्नल है, कोई सामान्य एरर या ऑथराइजेशन स्थिति नहीं।
इंटरव्यूअर क्या जांच रहा है
- 203, 200, 304, 4xx और 5xx के बीच सटीक सीमाएं।
- यह समझना कि ट्रांसफॉर्मेशन कैश, ETags, सिग्नेचर और बाद के अनुरोधों को कैसे प्रभावित करता है।
- ओरिजिन और डाउनस्ट्रीम रिप्रेजेंटेशन के बीच एक ट्रेसेबल ऑडिट लिंक।
- मल्टीपल प्रॉक्सी, ओरिजिन विफलताओं और ऐसे क्लाइंट्स को संभालना जो 203 को नहीं समझते हैं।
- प्रोटोकॉल सिमेंटिक्स को टेस्ट करने योग्य हेडर और कैश व्यवहार में बदलना।
उत्तर देने से पहले स्पष्टीकरण
- क्या परिवर्तन मैलवेयर फ़िल्टरिंग, ट्रांसकोडिंग या उपयोगकर्ता-विशिष्ट रिडेक्शन है? यह कैश शेयरिंग को प्रभावित करता है।
- क्या क्लाइंट 203 को पहचान सकते हैं? यदि नहीं, तो क्या एक कम्पैटिबिलिटी लेयर की आवश्यकता है?
- क्या मूल रिप्रेजेंटेशन ट्रेसेबल होना चाहिए? सिग्नेचर और ऑडिट रिकॉर्ड को दोनों वर्शन की आवश्यकता होती है।
- क्या ट्रांसफॉर्मेशन नियतात्मक (deterministic) है? यदि नियम बदलते हैं, तो नियम का वर्शन कैश की (cache key) में आता है।
30-सेकंड का उत्तर ढांचा
पहले मैं सत्यापित करता हूं कि क्या गेटवे ने एप्लिकेशन कंटेंट या प्रासंगिक हेडर को बदला है। बदले हुए रिप्रेजेंटेशन वाले सफल ओरिजिन रिस्पॉन्स को 203 मिलता है; एक अछूता (untouched) रिप्रेजेंटेशन 200 पर रहता है। 203 उस 304 को प्रतिस्थापित नहीं करता है, जो केवल क्लाइंट के मौजूदा रिप्रेजेंटेशन को मान्य करता है। मैं डाउनस्ट्रीम रिप्रेजेंटेशन के लिए एक ETag जनरेट करता हूं और कैश की में कंटेंट नेगोशिएशन, नियम वर्शन और टेनेंट सीमाओं को शामिल करता हूं। ऑडिट रिकॉर्ड ओरिजिन वर्शन को ट्रांसफॉर्म किए गए आउटपुट से जोड़ते हैं। ओरिजिन विफलताएं अपने वास्तविक विफलता सिमेंटिक्स को बनाए रखती हैं।
चरण-दर-चरण गहन उत्तर
1. स्टेटस-कोड की सीमाएं स्थापित करें
200 कहता है कि वर्तमान रिस्पॉन्स किसी एप्लिकेशन ट्रांसफॉर्मेशन की घोषणा किए बिना सफल रहा। 203 कहता है कि अनुरोध सफल रहा लेकिन एक ट्रांसफॉर्मिंग प्रॉक्सी ने ओरिजिन के 200 से हेडर या कंटेंट को बदल दिया। 304 कोई नया रिप्रेजेंटेशन नहीं ले जाता है और क्लाइंट से मान्य किए गए रिप्रेजेंटेशन का पुन: उपयोग करने के लिए कहता है। फ़िल्टरिंग विफलता, अस्वीकृति और ओरिजिन टाइमआउट अपने उपयुक्त 4xx या 5xx सिमेंटिक्स का उपयोग करते हैं।
2. ट्रांसफॉर्मेशन को वर्गीकृत करें
मैलवेयर-अवरुद्ध URL को बदलना, गोपनीयता फ़िल्टरिंग, प्रारूप ट्रांसकोडिंग, और मिरर मेटाडेटा 203 को उचित ठहरा सकते हैं। केवल ट्रांसफर कम्प्रेशन या हॉप-बाय-हॉप फ़ील्ड को बदलने से सामान्यतः एप्लिकेशन रिप्रेजेंटेशन नहीं बदलता है। गेटवे को यह रिकॉर्ड करना चाहिए कि क्या बदला और क्यों।
3. वैलिडेटर्स की पुनर्गणना करें
एक ओरिजिन ETag ओरिजिन रिप्रेजेंटेशन का वर्णन करता है। ट्रांसफॉर्म किए गए आउटपुट को एक डाउनस्ट्रीम ETag की आवश्यकता होती है जो उस आउटपुट के लिए मान्य हो। यदि कोई नियम वर्शन बाइट्स बदलता है, तो इसे कैश की या वैलिडेटर इनपुट में शामिल करें; अन्यथा एक नियम रोलआउट पुराने आउटपुट का पुन: उपयोग कर सकता है।
4. कैशिंग और नेगोशिएशन डिज़ाइन करें
Vary, कंटेंट एन्कोडिंग, भाषा, टेनेंट और ट्रांसफॉर्मेशन नियम सभी शेयर करने की क्षमता को प्रभावित करते हैं। डिफ़ॉल्ट रूप से गोपनीयता-संवेदनशील परिणामों को प्राइवेट कैशिंग में रखें; केवल नियतात्मक सार्वजनिक ट्रांसफॉर्मेशन को शेयर करें। If-None-Match के लिए, उन बाइट्स के लिए ओरिजिन 304 को अग्रेषित करने के बजाय गेटवे के रिप्रेजेंटेशन को मान्य करें जो क्लाइंट के पास नहीं हैं।
5. सिग्नेचर और ऑडिट ट्रेल्स को सुरक्षित करें
मूल बाइट्स पर एक ओरिजिन सिग्नेचर संशोधित डाउनस्ट्रीम बॉडी को प्रमाणित नहीं कर सकता है। ट्रांसफॉर्म किए गए रिप्रेजेंटेशन पर फिर से हस्ताक्षर करें या अमान्य सिग्नेचर को हटा दें। ओरिजिन अनुरोध ID, ओरिजिन ETag, नियम वर्शन, आउटपुट ETag और ट्रांसफॉर्मेशन का कारण लॉग करें।
6. मल्टीपल प्रॉक्सी को संभालें
प्रत्येक लेयर को ट्रांसफॉर्मेशन के स्रोत को बनाए रखना चाहिए और एक गैर-इडेम्पोटेंट (non-idempotent) नियम को दोहराने से बचना चाहिए। यदि कोई क्लाइंट 203 को नहीं समझ सकता है, तो एक स्पष्ट कम्पैटिबिलिटी लेयर प्रलेखित मेटाडेटा के साथ 200 लौटा सकती है, लेकिन इसे सुरक्षा या गोपनीयता ट्रांसफॉर्मेशन को चुपचाप नहीं छिपाना चाहिए।
7. सत्यापित करें और रोलबैक करें
ओरिजिन 200, ट्रांसफॉर्म किए गए 203, अछूते 200, डाउनस्ट्रीम 304, नियम रोलआउट, ओरिजिन टाइमआउट और फ़िल्टर विफलता का परीक्षण करें। रोलबैक के दौरान, सुनिश्चित करें कि पुराने और नए ETags टकरा न सकें और पुराने नियम के तहत बनाई गई साझा कैश प्रविष्टियों का निरीक्षण करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं 203 को इस घोषणा के रूप में मानता हूं कि "अनुरोध सफल रहा, लेकिन एक ट्रांसफॉर्मिंग प्रॉक्सी ने ओरिजिन रिप्रेजेंटेशन को बदल दिया।" एक अछूता एप्लिकेशन रिस्पॉन्स 200 रहता है; एक ट्रांसफॉर्म किया गया रिस्पॉन्स 203 होता है; 304 केवल डाउनस्ट्रीम रिप्रेजेंटेशन को मान्य करता है और इसे ओरिजिन से आंख मूंदकर पास नहीं किया जा सकता है। गेटवे ट्रांसफॉर्म किए गए बाइट्स के लिए एक नया ETag बनाता है और नियम वर्शन, नेगोशिएशन और गोपनीयता सीमा द्वारा कैशिंग को की करता है। यदि ओरिजिन सिग्नेचर मूल बाइट्स को कवर करता था, तो गेटवे फिर से हस्ताक्षर करता है या इसे हटा देता है। परीक्षण 200/203/304, नियम परिवर्तन, प्रॉक्सी चेन और ओरिजिन विफलताओं को कवर करते हैं ताकि क्लाइंट कभी भी फ़िल्टर किए गए डेटा को ओरिजिन डेटा समझने की भूल न करें।
सामान्य गलतियाँ
- प्रत्येक प्रॉक्सी रिस्पॉन्स के लिए 203 लौटाना → सिमेंटिक्स में अनावश्यक शोर उत्पन्न होता है → इसका उपयोग केवल वास्तविक रिप्रेजेंटेशन परिवर्तन के लिए करें।
- ओरिजिन ETag का पुन: उपयोग करना → वैलिडेटर्स गलत बाइट्स का वर्णन करते हैं → डाउनस्ट्रीम आउटपुट के लिए एक ETag जनरेट करें।
- 203 को एरर के रूप में मानना → क्लाइंट फिर से प्रयास कर सकते हैं या अलर्ट दे सकते हैं → वास्तविक 4xx/5xx विफलता सिमेंटिक्स को बनाए रखें।
- ओरिजिन 304 को आंख मूंदकर अग्रेषित करना → ट्रांसफॉर्म किया गया कैश मान्य नहीं हो सकता है → डाउनस्ट्रीम रिप्रेजेंटेशन को मान्य करें।
- नियम वर्शन्स को अनदेखा करना → रोलआउट पुराना आउटपुट दे सकते हैं → कीज या वैलिडेटर्स में वर्शन शामिल करें।
फॉलो-अप प्रश्न और उत्तर
क्या केवल Content-Encoding बदलने के लिए 203 की आवश्यकता है?
आमतौर पर नहीं। ट्रांसफर एन्कोडिंग ट्रांसपोर्ट हैंडलिंग है; यदि एप्लिकेशन रिप्रेजेंटेशन अपरिवर्तित है, तो 200 रखें और सामान्य नेगोशिएशन नियम लागू करें।
क्या 203 रिस्पॉन्स को कैश द्वारा शेयर किया जा सकता है?
हाँ, यदि ट्रांसफॉर्मेशन नियतात्मक है, प्रत्येक भिन्न आयाम कीबद्ध (keyed) है, और कोई उपयोगकर्ता-निजी डेटा मौजूद नहीं है। टेनेंट-विशिष्ट आउटपुट निजी होना चाहिए।
क्या होगा यदि ओरिजिन 203 को गेटवे द्वारा फिर से ट्रांसफॉर्म किया जाता है?
दोनों स्रोत लिंक को बनाए रखें, एक अंतिम ETag की गणना करें और इडेम्पोटेंस (idempotence) को सत्यापित करें। यदि इडेम्पोटेंस की गारंटी नहीं है, तो केवल एक ट्रांसफॉर्मेशन की अनुमति दें।
क्या कोई कम्पैटिबिलिटी लेयर 203 को 200 में बदल सकती है?
पहचानने योग्य मेटाडेटा और ऑडिट लॉगिंग के साथ, स्पष्ट रूप से प्रलेखित होने पर यह ऐसा कर सकती है। इसे सुरक्षा फ़िल्टरिंग या गोपनीयता रिडेक्शन को चुपचाप नहीं छिपाना चाहिए।
क्या होगा यदि ओरिजिन 304 लौटाता है लेकिन स्थानीय स्तर पर कोई ट्रांसफॉर्म की गई वस्तु मौजूद नहीं है?
सीधे 304 न लौटाएं। एक प्रयोग करने योग्य रिप्रेजेंटेशन प्राप्त करें और इसे ट्रांसफॉर्म करें, या एक ऐसी विफलता लौटाएं जो अनुपलब्ध स्थानीय रिप्रेजेंटेशन को दर्शाती हो।