1. प्रश्न और संदर्भ
लॉगिन के बाद, एक पेज CDN, लोड बैलेंसर और सर्विस मेश के माध्यम से एक API तक पहुँचता है। कुछ उपयोगकर्ताओं को 431 Request Header Fields Too Large प्राप्त होता है; एक इनकॉग्निटो विंडो और curl काम करते हैं। स्टेटस सिमेंटिक्स, हॉप-दर-हॉप निदान, समाधान और रिलीज़ वैलिडेशन की व्याख्या करें। मान लें कि HTTP/1.1 या HTTP/2 का उपयोग किया जा सकता है और लॉग में पूर्ण कुकीज़ या ऑथराइजेशन मान शामिल नहीं हो सकते हैं।
2. साक्षात्कारकर्ता क्या मूल्यांकन करता है
- एक ओवरसाइज़्ड एग्रीगेट हेडर ब्लॉक को एक ओवरसाइज़्ड फ़ील्ड से अलग करना और यह जानना कि 431 अनुरोध प्रोसेसिंग से पहले क्लाइंट-एरर रिस्पांस है।
- केवल एप्लिकेशन सर्वर को बदलने के बजाय CDN, गेटवे, प्रॉक्सी और एप्लिकेशन के माध्यम से मापना।
- कुकी वृद्धि, डुप्लिकेट Set-Cookie मान, लंबे टोकन और फ़ॉरवर्डिंग हेडर को संभावित कारणों के रूप में पहचानना।
- सुरक्षा को कमजोर किए बिना क्लाइंट स्थिति को कम करना, क्रेडेंशियल्स को रोटेट करना और आकार की ऑब्सर्वेबिलिटी जोड़ना।
3. पहले स्पष्ट करने योग्य प्रश्न
- किस हॉप ने 431 उत्पन्न किया, और क्या रिस्पांस हेडर, सर्वर पहचान या एज लॉग इसे पहचान सकते हैं?
- विफल अनुरोध के कुल हेडर बाइट्स, सबसे बड़ा फ़ील्ड और प्रोटोकॉल क्या हैं?
- क्या ब्राउज़र पुरानी कुकीज़, क्रॉस-सबडोमेन कुकीज़, या बढ़ता हुआ सेशन डेटा भेजता है?
- क्या प्रत्येक लेयर एग्रीगेट हेडर, किसी फ़ील्ड, अनुरोध लाइन, या बफ़र्स को सीमित करती है, और क्या HTTP/2 डिकोडिंग सीमाएं हैं?
4. 30-सेकंड का उत्तर
431 का अर्थ है कि सर्वर ने अनुरोध को अस्वीकार कर दिया क्योंकि कुल अनुरोध हेडर या किसी फ़ील्ड ने अनुमत सीमा को पार कर लिया; RFC 6585 एक सार्वभौमिक बाइट सीमा को परिभाषित नहीं करता है। क्लाइंट से एज, गेटवे, प्रॉक्सी और एप्लिकेशन के माध्यम से रिडैक्ट किए गए योग और सबसे बड़े फ़ील्ड को मापें, फिर 431 लौटाने वाले पहले हॉप को खोजें। जब केवल ब्राउज़र विफल होते हैं, तो सीमाएं बढ़ाने से पहले कुकीज़, डुप्लिकेट Set-Cookie और ऑथराइजेशन का निरीक्षण करें। क्लाइंट स्थिति को हटाएं, टोकन को छोटा करें या सर्वर-साइड सेशन संदर्भों से बदलें, पुरानी कुकीज़ को समाप्त करें और हॉप्स में बजट को संरेखित करें। केवल क्षमता और डिनायल-ऑफ़-सर्विस विश्लेषण के बाद ही सीमा बढ़ाएं।
5. चरण-दर-चरण उत्तर
चरण 1: स्थिति और उत्सर्जक हॉप की पुष्टि करें
पार किए गए नोड्स, प्रोटोकॉल, रिस्पांस हेडर और कोरिलेशन ID रिकॉर्ड करें। सीधे ओरिजिन पर, CDN के चारों ओर, गेटवे के माध्यम से, और रिडैक्ट किए गए ब्राउज़र हेडर के साथ एक न्यूनतम अनुरोध को फिर से चलाएं; तुलना करें कि 431 पहली बार कहाँ दिखाई देता है। कुछ प्रॉक्सी एक समान सीमा के लिए 400 या 494 जैसे वेंडर कोड का उपयोग करते हैं, इसलिए स्थिति को नोड लॉग और कॉन्फ़िगरेशन के साथ मिलाएं।
चरण 2: हेडर को बाइट्स में मापें
प्रत्येक फ़ील्ड के लिए एन्कोडेड बाइट लंबाई की गणना करें और कुल अनुरोध हेडर, अनुरोध लाइन, सबसे बड़ा फ़ील्ड और फ़ील्ड गणना रिकॉर्ड करें। वर्ण गणना बाइट गणना नहीं है, और एक संपीड़ित HTTP/2 हेडर ब्लॉक डिकोड किया गया फ़ील्ड योग नहीं है। लॉग में केवल फ़ील्ड नाम, लंबाई, हैश प्रीफ़िक्स और अनुरोध ID रखें; कुकी मान, बियरर टोकन, या पूर्ण Referer कभी रिकॉर्ड न करें।
चरण 3: केवल-ब्राउज़र स्रोतों को खोजें
कुकीज़ एक प्राथमिक संदिग्ध हैं: कई पाथ या सबडोमेन पर समान नाम वाली कुकीज़, कुकीज़ में संग्रहीत उपयोगकर्ता डेटा, और प्रत्येक रिस्पांस पर जोड़ा गया एक नया मान बाद के अनुरोधों को बढ़ाता है। Set-Cookie Domain, Path, समाप्ति और विलोपन व्यवहार का निरीक्षण करें; सत्यापित करें कि पुराना नाम केवल एक पाथ पर अधिलेखित होने के बजाय वास्तव में समाप्त हो जाता है। ऑथराइजेशन टोकन को छोटा रखें और परिवर्तनशील डेटा को नियंत्रित सर्वर-साइड सेशन या सुरक्षित स्टोर में रखें।
चरण 4: प्रॉक्सी हॉप्स और HTTP/2 का हिसाब रखें
प्रत्येक हॉप में अलग-अलग एग्रीगेट, प्रति-फ़ील्ड और बफ़र सीमाएं हो सकती हैं, जबकि फ़ॉरवर्डिंग X-Forwarded-*, ट्रेसिंग और प्रमाणीकरण फ़ील्ड जोड़ती है। बजट को कॉन्फ़िगरेशन अनुबंध के रूप में प्रकाशित करें और सबसे छोटी सीमा को क्लाइंट डिज़ाइन सीमा के रूप में उपयोग करें। HTTP/2 ट्रांसपोर्ट कम्प्रेशन के लिए HPACK का उपयोग करता है, लेकिन एंडपॉइंट अभी भी फ़ील्ड को डिकोड करते हैं और सीमाओं को लागू करते हैं; कम्प्रेशन अनुपात यह साबित नहीं करता कि व्यावसायिक हेडर सुरक्षित हैं। जब एप्लिकेशन को कुछ भी प्राप्त न हो तो गेटवे अस्वीकृति पर अलर्ट करें।
चरण 5: समाधान और सुरक्षा उपाय चुनें
डुप्लिकेट कुकीज़ हटाएं, सेशन सामग्री को कम करें, स्थिति को सर्वर-साइड ले जाएं, और केवल एक अनअनुमानित छोटा संदर्भ भेजें। टोकन लंबाई, रोटेशन और निरस्तीकरण नीतियां सेट करें; अज्ञात या असामान्य रूप से बड़े कस्टम फ़ील्ड को अस्वीकार करें। पार्सिंग मेमोरी, समवर्तीता और डिनायल-ऑफ़-सर्विस लागत की जांच करने के बाद ही सीमाएं बढ़ाएं, जिसमें प्रति-टेनेंट या प्रति-रूट समझदार बजट हो।
6. मॉडल उत्तर
मैं 431 लौटाने वाले पहले हॉप की पहचान करूँगा और रिडैक्शन के बाद विफल अनुरोध को मापूँगा: कुल हेडर बाइट्स, सबसे बड़ा फ़ील्ड, अनुरोध लाइन, फ़ील्ड गणना और HTTP संस्करण। केवल-ब्राउज़र विफलता पहले डुप्लिकेट या क्रॉस-सबडोमेन कुकीज़, बढ़ते सेशन डेटा, या ऑथराइजेशन लंबाई की ओर संकेत करती है; केवल ओरिजिन सीमा को बदलना असुरक्षित है क्योंकि CDN, लोड बैलेंसर, या मेश पहले अस्वीकार कर सकते हैं। मैं पुरानी कुकीज़ को समाप्त करूँगा, क्लाइंट स्थिति को कम करूँगा, सर्वर-साइड सेशन संदर्भ का उपयोग करूँगा, और हॉप बजट को संरेखित करूँगा। HTTP/2 ट्रांसपोर्ट कम्प्रेशन डिकोड की गई सीमाओं को नहीं हटाता है। प्रोडक्शन टेलीमेट्री क्रेडेंशियल्स को कभी भी संग्रहीत न करते हुए, लंबाई और हैश प्रीफ़िक्स संग्रहीत करके हॉप और फ़ील्ड नाम के आधार पर आकार प्रतिशत को एकत्रित करेगी।
7. सामान्य गलतियाँ
- केवल ब्राउज़र कुकीज़ साफ़ करना: यह अस्थायी हो सकता है; डुप्लिकेट
Set-Cookieमूल कारण को हटाने के लिए सेटर, Domain, Path, और समाप्ति तर्क का पता लगाएं। - यह मान लेना कि 431 का अर्थ हमेशा 8 KB होता है: RFC 6585 कोई सार्वभौमिक सीमा निर्धारित नहीं करता है; प्रत्येक लेयर का निरीक्षण करें और बाइट्स मापें।
- केवल ओरिजिन सीमा बढ़ाना: एक एज या गेटवे अभी भी पहले अस्वीकार कर सकता है, और पार्सिंग लागत बढ़ती है; बजट को संरेखित करें और क्षमता का आकलन करें।
- पूर्ण अनुरोध हेडर लॉग करना: यह कुकीज़ और टोकन को उजागर करता है; नाम, लंबाई, हैश प्रीफ़िक्स और कोरिलेशन ID बनाए रखें।
- यह मान लेना कि HTTP/2 कम्प्रेशन सीमाओं को हटा देता है: एंडपॉइंट फ़ील्ड को डिकोड करते हैं और सीमाओं को लागू करते हैं; ट्रांसपोर्ट कम्प्रेशन का परीक्षण डिकोड किए गए आकार से अलग करें।
8. फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: curl क्यों काम करता है जबकि ब्राउज़र विफल रहता है?
ब्राउज़र स्वचालित रूप से डोमेन से मेल खाने वाले प्रत्येक कुकी, प्रमाणीकरण और ट्रैकिंग हेडर भेजते हैं; curl आमतौर पर छोटा होता है। एक ब्राउज़र अनुरोध निर्यात करें, बाइनरी खोज द्वारा फ़ील्ड हटाएं, और क्लाइंट सामग्री को प्रॉक्सी सीमाओं से अलग करने के लिए प्रत्येक हॉप को मापें।
फॉलो-अप 2: क्या JWT को कुकी में संग्रहीत किया जा सकता है?
यह किया जा सकता है, लेकिन प्रत्येक अनुरोध टोकन की बाइट लागत का भुगतान करता है और कई कुकीज़ एक सीमा को पार कर सकती हैं। क्लाइंट-साइड एक छोटा संदर्भ या न्यूनतम दावे रखें, सर्वर-साइड परिवर्तनशील डेटा और निरस्तीकरण संग्रहीत करें, और लंबाई और रोटेशन बजट लागू करें।
फॉलो-अप 3: सीमा बढ़ाना कब स्वीकार्य है?
केवल तब जब आवश्यकता वास्तविक हो, प्रत्येक हॉप पार्सिंग मेमोरी और समवर्तीता को अवशोषित कर सके, और क्षमता, टाइमआउट और डिनायल-ऑफ़-सर्विस परीक्षण पास हो जाएं। आकार टेलीमेट्री, दर सीमाएं और एक रोलबैक कॉन्फ़िगरेशन बनाए रखें; एक उच्च सीमा ही एकमात्र समाधान नहीं है।