प्रॉम्प्ट और दायरा
WebDAV संसाधन बाइंडिंग्स के माध्यम से कई पाथ्स पर दिखाई दे सकते हैं। इसलिए एक रिकर्सिव कलेक्शन ट्रैवर्सल एक ही संसाधन पर दोबारा जा सकता है या हमेशा के लिए एक साइकिल का अनुसरण कर सकता है। RFC 5842 उसी multistatus रिस्पॉन्स में पहले से रिपोर्ट किए गए मेंबर्स के लिए 208 Already Reported और लूप का सामना करने के बाद ऑपरेशन समाप्त होने पर 508 Loop Detected को परिभाषित करता है।
इंटरव्यूअर क्या जांच रहा है
- क्या आप 508 को जेनेरिक गेटवे एरर मानने के बजाय इसके WebDAV संदर्भ में रखते हैं।
- क्या आप पहले से रिपोर्ट किए गए मेंबर के लिए 208 और समाप्त किए गए ऑपरेशन के लिए 508 में अंतर करते हैं।
- क्या गहराई, नोड काउंट, समय और रिस्पॉन्स बाइट्स लागू करने योग्य बजट बनते हैं।
- क्या क्लाइंट का व्यवहार आइडेम्पोटेंट, अवलोकनीय (observable), और अनंत पुनः प्रयासों (infinite retries) से मुक्त है।
स्पष्टीकरण हेतु प्रश्न
- क्या मेथड PROPFIND है, और क्या Depth को infinity पर सेट किया गया है?
- क्या संसाधन DAV बाइंडिंग्स का समर्थन करता है, और क्या क्लाइंट 208 को समझता है?
- क्या सर्वर को पूरा ट्री, एक सीमित परिणाम, या केवल सीमित गहराई लौटानी चाहिए?
- क्या कलेक्शन क्रॉस-टेनेंट है, और किन प्रॉपर्टीज का खुलासा किया जा सकता है?
30-सेकंड का उत्तर
मैं पहले सामान्य HTTP रीडायरेक्ट के बजाय WebDAV बाइंडिंग साइकिल की पुष्टि करूंगा। ट्रैवर्सल के दौरान मैं एक स्थिर संसाधन ID को ट्रैक करूंगा और गहराई, नोड, समय और रिस्पॉन्स-बाइट बजट लागू करूंगा। यदि क्लाइंट 208 को समझता है, तो पहले से रिपोर्ट किए गए मेंबर को इस रूप में दर्शाया जा सकता है; जब ट्रैवर्सल सक्रिय रिकर्शन स्टैक पर वापस लौटता है और सुरक्षित रूप से पूरा नहीं हो सकता, तो सर्वर 508 और एक स्थिर एरर बॉडी के साथ समाप्त होता है। क्लाइंट को उसी अनंत-गहराई वाले अनुरोध को आँख मूंदकर पुनः प्रयास नहीं करना चाहिए; उसे गहराई कम करनी चाहिए या बाइंडिंग की मरम्मत का अनुरोध करना चाहिए।
गहन उत्तर
1. 508 की सीमा परिभाषित करें
508 का अर्थ है कि सर्वर ने एक WebDAV ऑपरेशन को समाप्त कर दिया क्योंकि अनंत-गहराई सिमेंटिक्स को प्रोसेस करते समय उसे एक लूप का सामना करना पड़ा। यह भरी हुई डिस्क, अपस्ट्रीम टाइमआउट, या हर रिकर्सिव विफलता के लिए जेनेरिक कोड नहीं है। एरर बॉडी में एक स्थिर कोड और रिक्वेस्ट ID शामिल हो सकती है, लेकिन इसमें किसी अन्य टेनेंट के पाथ्स या आंतरिक टोपोलॉजी को उजागर नहीं किया जाना चाहिए।
2. बाइंडिंग पहचान को ट्रैक करें
केवल वर्तमान URL की तुलना करने के बजाय ट्रैवर्स करते समय DAV resource-id या किसी अन्य स्थिर संसाधन पहचान का उपयोग करें। एक संसाधन के कई पाथ हो सकते हैं, इसलिए केवल-URL डिडुप्लीकेशन उपनामों (aliases) को छोड़ देता है; स्थिर पहचान एक वैध उपनाम को साइकिल माने बिना दोहराए गए मेंबर्स का पता लगाती है।
3. 208 या 508 चुनें
जब क्लाइंट और रिस्पॉन्स सिमेंटिक्स इसकी अनुमति देते हैं, तो उसी multistatus परिणाम में पहले से मौजूद मेंबर को 208 के रूप में चिह्नित किया जा सकता है जबकि अन्य सुलभ मेंबर्स जारी रहते हैं। यदि ट्रैवर्सल सक्रिय रिकर्शन स्टैक में किसी संसाधन पर वापस लौटता है और ऑपरेशन सुरक्षित रूप से जारी नहीं रह सकता है, तो रुकें और 508 लौटाएं। इनके अर्थ क्रमशः "पहले से रिपोर्ट किया गया" और "लूप के कारण समाप्त" हैं।
4. संसाधन बजट लागू करें
एक गैर-चक्रीय (acyclic) ग्राफ़ को भी अधिकतम गहराई, अद्वितीय नोड्स, रिकर्शन स्टैक, रिस्पॉन्स बाइट्स और वॉल-क्लॉक समय की सीमाओं की आवश्यकता होती है। बजट समाप्त होने पर, एक स्थिर एप्लिकेशन एरर या सीमित-परिणाम नीति का उपयोग करें और कारण रिकॉर्ड करें। किसी बड़े कलेक्शन को अनियंत्रित CPU, मेमोरी या नेटवर्क बैंडविड्थ का उपभोग न करने दें।
5. क्लाइंट रिकवरी डिज़ाइन करें
508 के बाद, क्लाइंट को रिक्वेस्ट ID और संसाधन संदर्भ को बनाए रखना चाहिए और उसी अनंत-गहराई वाले अनुरोध को स्वचालित रूप से पुनः प्रयास करना बंद कर देना चाहिए। यह सीमित गहराई, खंडित रीड्स का उपयोग कर सकता है, या व्यवस्थापक द्वारा बाइंडिंग की मरम्मत करने की प्रतीक्षा कर सकता है। यदि Retry-After मान प्रदान किया गया है, तो यह इस बात का प्रमाण नहीं है कि साइकिल गायब हो गई है।
6. समवर्तीता (Concurrency) और कैशिंग
एक ही ग्राफ़ के समवर्ती ट्रैवर्सल के लिए अभी भी प्रति-अनुरोध बजट और रद्दीकरण की आवश्यकता होती है। कैश प्रॉपर्टी रीड्स को कम कर सकते हैं, लेकिन वे प्राधिकरण को बायपास नहीं कर सकते या एक टेनेंट के ग्राफ़ को दूसरे के लिए पुन: उपयोग नहीं कर सकते। किसी साइकिल की मरम्मत के बाद, प्रभावित कैश और सारांशों को संस्करण या चेंज टोकन द्वारा अमान्य करें।
7. सत्यापन और अवलोकनीयता
सेल्फ-बाइंडिंग्स, दो-नोड साइकिल, उपनाम, सीमित और अनंत गहराई, 208 को न समझने वाले क्लाइंट्स, बजट समाप्ति, रद्दीकरण रेस और अनुमति परिवर्तनों का परीक्षण करें। टेनेंट द्वारा खंडित पता लगाए गए साइकिल, अद्वितीय नोड्स, ट्रैवर्सल समय, रिस्पॉन्स बाइट्स, 508 दर, 208 दर और पुनः प्रयासों की निगरानी करें।
मॉडल उत्तर
508 एक साइकिल मिलने के बाद WebDAV बाइंडिंग ट्रैवर्सल को समाप्त करने का स्पष्ट परिणाम है। मैं सक्रिय रिकर्शन स्टैक और स्थिर संसाधन ID का उपयोग करके पहले से रिपोर्ट किए गए सेट को बनाए रखूंगा; जब क्लाइंट इसका समर्थन करता है तो पहले से रिपोर्ट किया गया मेंबर 208 का उपयोग कर सकता है, जबकि सक्रिय स्टैक पर लौटने पर 508 उत्पन्न होता है। प्रत्येक अनुरोध में गहराई, नोड, समय और बाइट बजट होते हैं, और एरर बॉडी में केवल एक स्थिर कोड और रिक्वेस्ट ID होती है। क्लाइंट उसी अनंत-गहराई वाले अनुरोध को पुनः प्रयास करना बंद कर देता है और सीमित ट्रैवर्सल या बाइंडिंग मरम्मत पर स्विच करता है। लोड परीक्षण साइकिल, बजट और पुनः प्रयास मेट्रिक्स के साथ साइकिल, उपनाम, अनुमतियों और रद्दीकरण को कवर करते हैं।
सामान्य गलतियाँ
- 508 को किसी भी 5xx के रूप में मानना → क्लाइंट लक्षित समाधान नहीं चुन सकता → इसे बाइंडिंग-लूप संदर्भ के लिए उपयोग करें।
- URL द्वारा डिडुप्लीकेट करना → उपनाम छूट जाते हैं या गलत वर्गीकृत हो जाते हैं → स्थिर संसाधन पहचान का उपयोग करें।
- 208 को लूप एरर के रूप में मानना → रिपोर्ट किए गए मेंबर को समाप्ति के साथ भ्रमित किया जाता है → 208 का अर्थ है कि मेंबर पहले ही रिपोर्ट किया जा चुका था।
- 508 का हमेशा के लिए पुनः प्रयास करना → डायरेक्टरी की समस्या संसाधनों का उपभोग करती रहती है → गहराई कम करें या बाइंडिंग की मरम्मत करें।
फॉलो-अप प्रश्न
क्या 208 और 508 एक ही रिस्पॉन्स में दिखाई दे सकते हैं?
हाँ। कुछ मेंबर्स को 208 के रूप में चिह्नित किया जा सकता है क्योंकि वे पहले ही रिपोर्ट किए जा चुके थे; बाद की साइकिल के कारण अभी भी समग्र ऑपरेशन 508 के साथ समाप्त हो सकता है। रिस्पॉन्स संरचना को WebDAV multistatus सिमेंटिक्स का पालन करना चाहिए।
क्या रिकर्शन-गहराई की सीमा पर्याप्त है?
नहीं। एक विस्तृत, उथला (shallow) कलेक्शन अभी भी कई नोड्स और एक बड़ा रिस्पॉन्स बना सकता है, इसलिए अद्वितीय नोड्स, बाइट्स, CPU और वॉल-क्लॉक समय को भी सीमित करें।
क्या रिवर्स प्रॉक्सी को 508 को 500 में फिर से लिखना (rewrite) चाहिए?
आमतौर पर नहीं। स्टेटस और स्थिर एरर फ़ील्ड्स को सुरक्षित रखें। यदि किसी बाहरी अनुबंध के लिए मैपिंग की आवश्यकता है, तो लॉग में मूल कारण बनाए रखें और सुनिश्चित करें कि क्लाइंट अभी भी पुनः प्रयास करना बंद कर दे।
आप कैसे साबित करते हैं कि सुधार के बाद भी उपनाम काम कर रहे हैं?
एक शेयर्ड बाइंडिंग के साथ एक अचक्रीय (acyclic) ग्राफ़ का परीक्षण करें: कई पाथ्स के माध्यम से पहुँची गई समान संसाधन ID को 208 या समकक्ष डिडुप्लीकेशन उत्पन्न करना चाहिए, जबकि प्राधिकरण प्रत्येक पाथ के लिए स्वतंत्र रूप से जाँचा जाता रहता है।