सामान्य साक्षात्कार: आपको HTTP 507 Insufficient Storage की व्याख्या कैसे करनी चाहिए?

प्रॉम्प्ट और संदर्भ

यह HTTP और API फंडामेंटल्स प्रॉम्प्ट बैकएंड, प्लेटफॉर्म, SRE और इंफ्रास्ट्रक्चर भूमिकाओं के लिए उपयुक्त है। एक अनुरोध सिद्धांत रूप में मान्य होगा, लेकिन सर्वर परिणामी संसाधन स्थिति को संग्रहीत नहीं कर सकता क्योंकि कोटा, फाइलसिस्टम, मेमोरी बजट या एप्लिकेशन सीमा समाप्त हो गई है। बताएं कि 507 कब सार्थक है, कब कोई अन्य स्टेटस अधिक सटीक है, और किसी राइट (write) को डुप्लिकेट किए बिना कैसे रिकवर किया जाए।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

• क्या आप सर्वर-साइड क्षमता की कमी को उस अनुरोध से अलग कर सकते हैं जो स्वाभाविक रूप से बहुत बड़ा है?
• क्या आप जानते हैं कि 507 की उत्पत्ति WebDAV में हुई थी और यह एक सामान्य सत्यापन त्रुटि के बजाय एक अस्थायी सर्वर स्थिति है?
• क्या आप कारण को छिपाए बिना पुनः प्रयास (retry), बैकऑफ़, इडेम्पोटेंसी (idempotency), और उपयोगकर्ता-उन्मुख समाधान को परिभाषित कर सकते हैं?
• क्या आप एप्लिकेशन, स्टोरेज, कोटा, प्रॉक्सी और कैश परतों में सीमा का पता लगा सकते हैं?

पूछने के लिए स्पष्टीकरण संबंधी प्रश्न

पूछें कि कौन सा ऑपरेशन विफल हुआ, क्या अनुरोधित प्रतिनिधित्व मान्य है, कौन सी संसाधन सीमा पूरी हुई, क्या सीमा टेनेंट-विशिष्ट है, और क्या ऑपरेशन पहले से ही आंशिक स्थिति को कमिट कर चुका है। पुष्टि करें कि क्या क्लाइंट सुरक्षित रूप से पुनः प्रयास कर सकता है और क्या सेवा कोई कोटा या क्षमता संकेत प्रदर्शित करती है। यदि पेलोड खाली क्षमता की परवाह किए बिना नीति या पार्सर सीमा से अधिक है, तो 413 का उपयोग करें; यदि सेवा व्यापक प्रसंस्करण कारणों से अस्थायी रूप से अनुपलब्ध है, तो 503 अधिक उपयुक्त हो सकता है। केवल इसलिए 507 का चयन न करें क्योंकि पूरे फ्लीट में कहीं डिस्क अलर्ट मौजूद है।

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

मैं 507 तब लौटाऊंगा जब अनुरोधित ऑपरेशन अन्यथा मान्य हो लेकिन सर्वर परिणामी संसाधन स्थिति को रिकॉर्ड नहीं कर सकता क्योंकि उपलब्ध स्टोरेज या लागू सर्वर सीमा समाप्त हो गई है। मैं इसे 413 से अलग करूंगा, जो अनुरोध के बहुत बड़े होने के बारे में है, और 503 से, जो व्यापक अस्थायी अनुपलब्धता का प्रतिनिधित्व करता है। प्रतिक्रिया में आंतरिक पथों को लीक किए बिना एक स्थिर त्रुटि प्रकार और अनुरोध आईडी को उजागर किया जाना चाहिए। क्लाइंट केवल तभी पुनः प्रयास करता है जब ऑपरेशन इडेम्पोटेंट हो या उसके पास इडेम्पोटेंसी कुंजी हो, वह भी सीमित बैकऑफ़ के साथ; ऑपरेटर ठीक समाप्त हुए आयाम को मापता है, क्षमता को मुक्त या विस्तारित करता है, और रिकवरी घोषित करने से पहले एक पूर्ण राइट को सत्यापित करता है।

चरण-दर-चरण गहन विश्लेषण

1. विफलता को वर्गीकृत करें। RFC 4918 उस विधि के लिए 507 को परिभाषित करता है जो निष्पादन के बाद संसाधन स्थिति को रिकॉर्ड नहीं कर सकती क्योंकि गंतव्य में पर्याप्त स्थान का अभाव है। MDN नोट करता है कि कार्यान्वयन इसका उपयोग समाप्त सर्वर संसाधनों या एप्लिकेशन सीमाओं के लिए भी करते हैं। मुख्य शर्त सर्वर-साइड क्षमता सीमा द्वारा अवरुद्ध एक मान्य क्रिया है।
2. निकटवर्ती स्थितियों को अलग करें। वर्तमान क्षमता से स्वतंत्र सामग्री बहुत बड़ी होने पर 413 लौटाएं। स्थिति विरोध या पूर्व-शर्त विफल होने पर 409 या 412 लौटाएं। 503 तब लौटाएं जब सेवा सामान्य रूप से अनुरोधों को संसाधित नहीं कर सकती है और Retry-After प्रदान कर सकती है। 507 प्रतिक्रिया हर राइट विफलता के लिए कैच-ऑल नहीं बननी चाहिए।
3. विफलता को कार्रवाई योग्य बनाएं। एक स्थिर समस्या प्रकार, मानव-पठनीय शीर्षक, अनुरोध आईडी और पुनः प्रयास संकेत का उपयोग केवल तभी करें जब क्षमता के ठीक होने की उम्मीद हो। टेनेंट कोटा में एक सुरक्षित कोटा पहचानकर्ता या समाधान लिंक शामिल हो सकता है, जबकि फाइलसिस्टम पथ, होस्टनाम और गुप्त नीति विवरण आंतरिक रहते हैं।
4. पुनः प्रयासों को सुरक्षित रखें। टाइम-आउट अपलोड में अज्ञात कमिट स्थिति हो सकती है। एक इडेम्पोटेंसी कुंजी या फिर से शुरू करने योग्य (resumable) अपलोड टोकन की आवश्यकता रखें, ऑपरेशन स्थिति को बनाए रखें, और फिर से चलाने से पहले क्लाइंट से स्थिति के बारे में पूछताछ करवाएं। समय सीमा (deadline) के साथ घातीय बैकऑफ़ (exponential backoff) लागू करें; असीमित पुनः प्रयास एक भरे हुए सिस्टम को और खराब कर सकते हैं।
5. संसाधन सीमा का पता लगाएं। मुक्त बाइट्स या इनोड्स (inodes), ऑब्जेक्ट-स्टोर कोटा, डेटाबेस/ब्लॉब स्टेजिंग उपयोग, मेमोरी सीमा, टेनेंट आवंटन, और 507 उत्सर्जित करने वाली परत को रिकॉर्ड करें। स्टोरेज मेट्रिक्स और अनुरोध आईडी के साथ एप्लिकेशन लॉग की तुलना करें ताकि प्रॉक्सी-जनरेटेड त्रुटि को ओरिजिन का निर्णय न समझ लिया जाए।
6. रिकवर करें और सत्यापित करें। यदि आवश्यक हो तो नए राइट्स को ड्रेन या अस्वीकार करें, क्षमता का विस्तार या पुनः प्राप्त करें, और मूल इडेम्पोटेंसी कुंजी का उपयोग करके एक सीमित राइट को फिर से चलाएं। ऑब्जेक्ट चेकसम, मेटाडेटा, दृश्यता और कोटा लेखांकन को सत्यापित करें। पुनरावृत्ति पर अलर्ट सेट करें और परीक्षण करें कि एक पूर्ण टेनेंट दूसरे टेनेंट के आरक्षण का उपभोग नहीं कर सकता है।

एक मजबूत उत्तर का उदाहरण

मैं 507 का उपयोग केवल तभी करूंगा जब अनुरोध मान्य हो लेकिन सर्वर स्टोरेज या सर्वर संसाधन सीमा समाप्त होने के कारण परिणामी स्थिति को बनाए नहीं रख सकता है। एक पेलोड जो हमेशा बहुत बड़ा होता है वह 413 है, और एक व्यापक रखरखाव या ओवरलोड स्थिति 503 हो सकती है। मैं एक स्थिर समस्या प्रकार और अनुरोध आईडी लौटाऊंगा, साथ ही केवल तभी पुनः प्रयास संकेत दूंगा जब रिकवरी प्रशंसनीय हो:

HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120

{
  "type": "https://api.example.com/problems/storage-exhausted",
  "title": "The resource could not be stored",
  "status": 507,
  "detail": "The workspace storage limit prevented this operation.",
  "request_id": "req-7f2"
}

क्लाइंट को ऐसे अपलोड को आंख मूंदकर दोबारा नहीं भेजना चाहिए जिसकी कमिट स्थिति अज्ञात हो। यह उसी इडेम्पोटेंसी कुंजी के साथ पुनः प्रयास करता है या पहले ऑपरेशन स्थिति के लिए पूछता है। ऑपरेटर अनुरोध को कोटा, स्टेजिंग, ऑब्जेक्ट-स्टोर, डेटाबेस और इनोड मेट्रिक्स के साथ सहसंबंधित करते हैं, फिर क्षमता बहाल होने के बाद चेकसम, दृश्यता और लेखांकन को सत्यापित करते हैं। यदि कोई गेटवे 507 उत्सर्जित करता है जबकि ओरिजिन 200 लौटाता है, तो मैं गेटवे को उत्सर्जक परत मानता हूं और प्रत्येक हॉप का स्वतंत्र रूप से परीक्षण करता हूं।

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

• अत्यधिक बड़े अनुरोध के लिए 507 लौटाना → क्षमता परिवर्तन उस पेलोड को मान्य नहीं बना सकते → एक निश्चित अनुरोध-आकार नीति के लिए 413 का उपयोग करें।
• हर 507 का तुरंत पुनः प्रयास करना → एक भरा हुआ संसाधन अधिक विवादित हो जाता है → सीमित बैकऑफ़ और एक ऑपरेशन समय सीमा का उपयोग करें।
• टाइमआउट के बाद अपलोड को दोबारा चलाना → मूल राइट कमिट हो चुका हो सकता है → स्थिति की पूछताछ करें या इडेम्पोटेंसी कुंजी का पुन: उपयोग करें।
• सीमा का पता लगाए बिना यह कहना कि "डिस्क भरी हुई है" → कोटा, इनोड्स, स्टेजिंग और ऑब्जेक्ट स्टोरेज स्वतंत्र रूप से विफल हो सकते हैं → उत्सर्जक परत और समाप्त आयाम की पहचान करें।
• क्लाइंट को कच्चे पथ और होस्टनाम रिपोर्ट करना → आंतरिक टोपोलॉजी और टेनेंट डेटा लीक हो सकता है → संरक्षित लॉग में डायग्नोस्टिक्स रखते हुए एक स्थिर समस्या प्रकार और अनुरोध आईडी लौटाएं।

अनुवर्ती प्रश्न और उत्तर

क्या क्लाइंट को HTTP 507 का पुनः प्रयास करना चाहिए?

केवल तभी जब ऑपरेशन का पुनः प्रयास करना सुरक्षित हो और क्षमता ठीक होने की उम्मीद हो। राइट्स के लिए इडेम्पोटेंसी कुंजी या स्थिति लुकअप, घातीय बैकऑफ़ और एक समय सीमा का उपयोग करें। यदि त्रुटि एक हार्ड टेनेंट कोटा का प्रतिनिधित्व करती है, तो पुनः प्रयास करने के बजाय समाधान प्रस्तुत करें।

आप 507 को 503 से कैसे अलग करते हैं?

507 किसी वैध संसाधन स्थिति को रिकॉर्ड करने में असमर्थता की पहचान करता है क्योंकि स्टोरेज या सर्वर सीमा समाप्त हो गई है। 503 अनुरोध को पूरा करने में व्यापक अस्थायी असमर्थता है और इसमें रखरखाव या ओवरलोड शामिल हो सकता है। केवल HTTP परत से अनुमान लगाने के बजाय मापी गई विफलता सीमा और सुसंगत सेवा नीति का उपयोग करें।

क्या होगा यदि ओरिजिन सफल रहा लेकिन एक प्रॉक्सी ने 507 लौटाया?

अनुरोध आईडी कैप्चर करें और ओरिजिन-डायरेक्ट, प्रॉक्सी और कैश-कोल्ड अनुरोधों की तुलना करें। प्रॉक्सी उत्सर्जक परत है और इसका अपना बफर या कोटा हो सकता है। पुनः प्रयास करने से पहले क्लाइंट की अंतिम स्थिति का मिलान करें, क्योंकि हो सकता है कि ओरिजिन में संसाधन पहले से ही मौजूद हो।