प्रॉम्प्ट और दायरा
आपको ब्राउज़र या एज रनटाइम में बाइनरी रिक्वेस्ट बॉडीज को प्रोसेस करना होगा। प्लेटफ़ॉर्म Request.bytes() जोड़ता है, लेकिन एक रिक्वेस्ट बॉडी को केवल एक बार ही उपभोग (consume) किया जा सकता है। बताएं कि इसका उपयोग कब करना है, डबल रीड से कैसे बचना है, मेमोरी को कैसे सीमित करना है, और फ़ॉलबैक कैसे डिज़ाइन करना है।
MDN में Request.bytes() को एक ऐसी Promise लौटाने के रूप में वर्णित किया गया है जिसका फुलफिल्ड मान रिक्वेस्ट बॉडी का Uint8Array होता है; बॉडी को पढ़ने से यह उपभोग हो जाती है। साक्षात्कार नए मेथड को एक सार्वभौमिक डिफ़ॉल्ट मानने के बजाय Fetch बॉडी के लाइफ़टाइम, संसाधन सीमाओं और त्रुटियों का परीक्षण करता है।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- यूज्ड-बॉडी स्थिति और
bytes(),arrayBuffer(),json(), औरtext()की परस्पर अपवर्जनता (mutual exclusivity) को स्पष्ट करना। - रिक्वेस्ट आकार और प्रोसेसिंग लक्ष्यों के आधार पर पूर्ण बनाम स्ट्रीमिंग रीड्स का चयन करना।
- पुनः प्रयासों (retries), लॉगिंग, हस्ताक्षर सत्यापन और व्यावसायिक पार्सिंग के बीच एक एकल रीड बाउंड्री स्थापित करना।
- क्षमता पहचान (capability detection), सीमाओं, रद्दीकरण, टाइमआउट्स और त्रुटि मैपिंग को डिज़ाइन करना।
- रॉ बॉडीज को लॉग्स, कैश या क्रॉस-टेनेंट ऑब्जेक्ट्स में जाने से रोकना।
स्पष्टीकरण प्रश्न
- बॉडी का आकार, स्रोत, Content-Type, हस्ताक्षर आवश्यकताएं और लक्षित रनटाइम क्या हैं?
- क्या व्यवसाय को एक संपूर्ण बाइट ऐरे, वृद्धिशील हैशिंग (incremental hashing), चंक अपलोड, या डिकोड किए गए डेटा की आवश्यकता है?
- कौन सी लेयर पुनः प्रयास करती है, और क्या रीप्ले सुरक्षित है?
- क्या बॉडी में व्यक्तिगत डेटा, क्रेडेंशियल्स, या टेनेंट-आइसोलेशन डेटा हो सकता है?
बॉडी लाइफ़टाइम और API का चयन
Request.bytes() द्वारा किसी बॉडी को सफलतापूर्वक उपभोग करने के बाद, बाद के json() या text() कॉल्स विफल हो जाते हैं, और इसका उल्टा भी सत्य है। यदि कई उपभोक्ताओं को डेटा की आवश्यकता है, तो एक ही सीमा पर एक बार पढ़ें और पार्सिंग, सत्यापन और व्यावसायिक कोड को नियंत्रित परिणाम पास करें। किसी Request ऑब्जेक्ट को ऐसे कई मॉड्यूल के माध्यम से पास न करें जो इसे पढ़ने के लिए प्रतिस्पर्धा करते हैं।
पूर्ण रीड्स सीमित छोटे अनुरोधों या ऐसे प्रोटोकॉल के लिए उपयुक्त हैं जिनके लिए वन-शॉट सत्यापन की आवश्यकता होती है। बड़े अनुरोधों के लिए request.body स्ट्रीमिंग को प्राथमिकता दी जानी चाहिए, जिसमें वृद्धिशील हैशिंग और आकार की जांच की जाती है। एक Uint8Array परिणाम बाइट प्रोसेसिंग के लिए सुविधाजनक है, लेकिन यह पूर्ण रीड के मेमोरी पीक को नहीं हटाता है।
मेमोरी, सीमाएं, और बैकप्रेशर
एज पर Content-Length की जांच करें, लेकिन केवल इसी पर भरोसा न करें; चंक्ड ट्रांसफर के साथ, वास्तविक बाइट्स की गणना करें और सीमा पार होने पर एबॉर्शन (abort) करें। पूर्ण रीड्स के लिए टेनेंट, रूट और वैश्विक सीमाएं निर्धारित करें ताकि समवर्ती अनुरोध असीमित ऐरे आवंटित न कर सकें। जब उपभोक्ता पीछे रह जाते हैं तो स्ट्रीमिंग पाथ्स बैकप्रेशर लागू करते हैं।
फ़ॉरवर्डिंग के लिए, लॉगिंग या पुनः प्रयास के लिए कई पूर्ण ऐरे की कॉपी न बनाएं। यदि रीप्ले की आवश्यकता है, तो टेनेंट बाइंडिंग, समाप्ति (expiry) और डाइजेस्ट के साथ नियंत्रित अस्थायी स्टोरेज में आकार-सीमित बाइट्स लिखें; रॉ बॉडीज साधारण लॉग्स से संबंधित नहीं हैं।
हस्ताक्षर सत्यापन, पार्सिंग, और त्रुटियां
सत्यापन से पहले, यह परिभाषित करें कि हस्ताक्षर रॉ बाइट्स को कवर करता है या किसी विहित संरचना (canonical structure) को। एकल रीड से प्राप्त रॉ बाइट्स को सत्यापनकर्ता और पार्सर दोनों को फीड करें; JSON री-सीरियलाइजेशन रिक्त स्थान (whitespace), क्रम या एन्कोडिंग को बदल सकता है। पार्स विफलता, हस्ताक्षर विफलता, आकार उल्लंघन, रद्दीकरण, और टाइमआउट को एक सामान्य "विकृत" (malformed) प्रतिक्रिया के बजाय अलग-अलग व्यावसायिक त्रुटियों में मैप करें।
एज फ़ंक्शन्स विभिन्न बॉडी APIs को प्रदर्शित कर सकते हैं। क्षमता का पता लगाएं और स्टार्टअप पर रनटाइम क्षमता संस्करण रिकॉर्ड करते हुए bytes(), arrayBuffer(), या स्ट्रीमिंग चुनें। फ़ॉलबैक को सीमाओं, डाइजेस्ट इनपुट और त्रुटि सिमेंटिक्स को बनाए रखना चाहिए; एक पुराने रनटाइम को सुरक्षा को चुपचाप कमजोर नहीं करना चाहिए।
रद्दीकरण, टाइमआउट्स, और रीप्ले
रीड्स और डाउनस्ट्रीम ऑपरेशन्स को एक AbortSignal पास करें। जब क्लाइंट डिस्कनेक्ट हो जाए या समय सीमा समाप्त हो जाए, तो पढ़ना बंद करें और संदर्भों (references) को रिलीज़ करें। आइडेम्पोटेंसी कुंजी, सर्वर डिडुप्लीकेशन और एक स्पष्ट पुनः प्रयास विंडो के बिना टाइमआउट के बाद कभी भी साइड-इफ़ेक्ट वाले अनुरोध को स्वचालित रूप से रीप्ले न करें। सुरक्षित दिखने वाली क्वेरीज़ को भी रीप्ले-लीक समीक्षा की आवश्यकता होती है।
गेटवे के पुनः प्रयास अनुरोध की प्रतियां बना सकते हैं, इसलिए हस्ताक्षर सत्यापन, आइडेम्पोटेंसी कुंजियों और ऑडिट इवेंट्स को एक ही रिक्वेस्ट ID साझा करनी चाहिए। एक त्रुटि प्रतिक्रिया को आंतरिक रीड स्थिति या कुंजी सामग्री को उजागर किए बिना यह बताना चाहिए कि क्या पुनः प्रयास सुरक्षित है।
सुरक्षा और ऑब्ज़र्वेबिलिटी
Content-Type, बॉडी आकार, पढ़ने की अवधि और समवर्तीता (concurrency) को सीमित करें। डीकंप्रेशन बमों का मुकाबला करने के लिए डीकंप्रेस किए गए आकार को ध्यान में रखें। टेनेंट द्वारा कैश और अस्थायी ऑब्जेक्ट्स को अलग करें; संवेदनशील बाइट्स को केवल तब तक रखें जब तक आवश्यक हो। बाइट गणना, अवधि, रद्दीकरण का कारण, त्रुटि वर्ग, और अनुरोध डाइजेस्ट रिकॉर्ड करें, सामग्री कभी नहीं।
बॉडी-कंजम्पशन विफलताओं, सीमा उल्लंघनों, p95 रीड समय, पीक मेमोरी, डाउनस्ट्रीम बैकप्रेशर और पुनः प्रयासों की निगरानी करें। यदि किसी रनटाइम में bytes() विफलताएं बढ़ती हैं, तो एक परीक्षण किए गए फ़ॉलबैक पर स्विच करें और अलर्ट करें; किसी अपवाद को पकड़ना और उसी बॉडी को फिर से पढ़ना रिकवरी नहीं है।
सत्यापन चेकलिस्ट और फ़ॉलो-अप
रिक्त, एक-बाइट, सीमा के निकट, सीमा से अधिक, चंक्ड, धीमे-क्लाइंट, डिस्कनेक्ट, डबल-रीड, हस्ताक्षर बेमेल, डीकंप्रेशन-बम, समवर्ती, पुराने-रनटाइम फ़ॉलबैक, और डाउनस्ट्रीम-टाइमआउट मामलों का परीक्षण करें। सत्यापित करें कि प्रत्येक पाथ बॉडी को ठीक एक बार उपभोग करता है और रद्दीकरण आगे के रीड्स को रोकता है।
json() को कॉल करने और फिर सत्यापन के लिए bytes() का उपयोग क्यों न करें?
पहले रीड ने बॉडी का उपभोग कर लिया है, और पार्सिंग के साथ री-सीरियलाइजेशन रिक्त स्थान, क्रम या एन्कोडिंग को बदल सकता है। रॉ बाइट्स को एक बार पढ़ें और उन्हीं बाइट्स को सत्यापन और पार्सिंग के लिए फीड करें।
स्ट्रीमिंग की तुलना में bytes() कब बेहतर है?
इसका उपयोग छोटे सीमित अनुरोधों के लिए करें जब प्रोटोकॉल को पूर्ण-बाइट सत्यापन की आवश्यकता हो। बड़ी फ़ाइलों, निरंतर अपलोड और उच्च समवर्तीता के लिए स्ट्रीमिंग और वृद्धिशील प्रसंस्करण की आवश्यकता होती है।
आप यह कैसे सिद्ध करते हैं कि फ़ॉलबैक समान रूप से सुरक्षित है?
प्रत्येक रनटाइम में प्रत्येक क्षमता पाथ को बाध्य करें और सीमाओं, डाइजेस्ट्स, हस्ताक्षरों, त्रुटियों, रद्दीकरण और ऑडिट इवेंट्स की तुलना करें। फ़ॉलबैक को सुरक्षा नीति या पुनः प्रयास सीमाओं को नहीं बदलना चाहिए।