क्या decoded size limits एजेंट को compressed APIs से बचाती हैं?

संपीड़ित जवाब छोटा नहीं होता सिर्फ इसलिए कि वह छोटा पहुंचा है। वह तभी तक छोटा है, जब तक आपका क्लाइंट उसे डिकोड, पार्स, स्टोर और लॉग नहीं करता, या उसे ऐसे एजेंट को नहीं देता जो उसे साक्ष्य मानता है। यदि आप केवल नेटवर्क से मिले बाइट पर सीमा लगाते हैं, तो आपने लेनदेन के सबसे कम महत्वपूर्ण हिस्से को मापा है।

मैंने टीमों को 5 MB की देखने में ठीक लगने वाली HTTP सीमा जोड़ते, टेस्ट सफल मानते और फिर यह पता लगाते देखा है कि कुछ kilobyte संपीड़ित दोहराया गया डेटा इतनी बड़ी प्रतिक्रिया बना सकता है कि प्रक्रिया रुक जाए या एजेंट रन दूषित हो जाए। किसी असाधारण exploit की जरूरत नहीं थी। एक endpoint ने ऐसी रिपोर्ट लौटाई जिसमें कोई field उम्मीद से बहुत अधिक बार दोहराई गई थी, compression ने बहुत अच्छी तरह काम किया और क्लाइंट ने खतरनाक काम किया: उसने यह तय करने से पहले decoded body जमा कर ली कि उसे वह चाहिए भी या नहीं।

Decoded size limit, decoded stream पर लगनी चाहिए, इससे पहले कि parser, logger, cache या agent context body को इस्तेमाल करे। Wire bytes के लिए अलग cap रखें, क्योंकि वह धीमे या अनपेक्षित रूप से बड़े transfer रोकता है। दोनों सीमाएं अलग विफलताओं से बचाती हैं। इन्हें गड्डमड्ड करने पर सुरक्षा जांच केवल झूठा भरोसा बन जाती है।

Wire size कहानी का केवल एक हिस्सा बताता है

Content-Length आम तौर पर भेजे गए HTTP message body का आकार बताता है। जब जवाब में Content-Encoding: gzip या Content-Encoding: br हो, तो यह गिनती संपीड़ित bytes की होती है। यदि input में पर्याप्त दोहराव हो, तो 40 KB की body डिकोड होने के बाद दर्जनों या सैकड़ों megabyte तक फैल सकती है। सटीक अनुपात मुद्दा नहीं है। जो भी अनुपात आपके allocation या context budget से ऊपर जाए, वह समस्या पैदा करने के लिए काफी है।

RFC 9110 content coding को representation पर लागू परिवर्तन मानता है। यह बात महत्वपूर्ण है। आपका application जिस representation को इस्तेमाल करता है, वह decoded form है, जबकि transport encoded form ले जाता है। जो क्लाइंट application limit को transport form पर आधारित करता है, उसने सुरक्षा guard परिवर्तन के गलत तरफ रखा है।

Transfer-Encoding से तस्वीर और जटिल हो जाती है। Chunked transfer में क्लाइंट के भरोसे के लिए कोई उपयोगी अंतिम Content-Length नहीं होता और HTTP/2 या HTTP/3 जवाब उसी तरह chunked transfer नहीं इस्तेमाल करते। Header होने पर भी सर्वर गलत मान भेज सकता है। Header को जल्दी अस्वीकार करने के संकेत की तरह इस्तेमाल करें, body के सुरक्षित होने के प्रमाण की तरह नहीं।

जवाब के लिए तीन मात्राएं दर्ज करना उपयोगी है: पढ़े गए wire bytes, बने decoded bytes और caller के लिए रखे गए bytes। कभी ये एक जैसे होंगे, अक्सर नहीं होंगे। कोई JSON जवाब 12 MB में डिकोड हो सकता है, पार्स होने पर 12 MB से बहुत अधिक मेमोरी ले सकता है और फिर एजेंट के सुरक्षित उपयोग के लिए उसे 64 KB तक छोटा करना पड़ सकता है।

यह अंतर एक ही «maximum response size» setting पर होने वाली आम बहस भी रोकता है। एक engineer से मतलब socket bytes होता है, दूसरे से decoded bytes और तीसरे से tool result में डाला गया text। हर सीमा को अलग नाम दें और जिस boundary का वह वर्णन करती है, वहीं लागू करें।

किसी भी असीमित buffering से पहले डिकोड करें

सुरक्षित क्रम सीधा है: raw response stream को सीमित करें, decoder चुनकर शुरू करें, decoded stream को सीमित करें, फिर केवल caller की जरूरत का डेटा पार्स या retain करें। ऐसी convenience method न बुलाएं जो पूरी decoded response को byte slice में पढ़ ले और बाद में उसकी लंबाई जांचे। तब तक decoder वही मेमोरी खर्च कर चुका होगा जिसे आप बचाना चाहते थे।

Go में gzip response के लिए decoded limiter, gzip reader के आसपास होना चाहिए। यह helper जानबूझकर allowed amount से एक byte अधिक पढ़ता है। उस अतिरिक्त byte के बिना, वास्तव में सीमा जितने आकार वाले जवाब और सीमा पर काटे गए बड़े जवाब में अंतर नहीं किया जा सकता।

var ErrDecodedBodyTooLarge = errors.New("decoded response exceeds limit")

func readGzipBody(r io.Reader, limit int64) ([]byte, error) {
    zr, err := gzip.NewReader(r)
    if err != nil {
        return nil, err
    }
    defer zr.Close()

    bounded := &io.LimitedReader{R: zr, N: limit + 1}
    body, err := io.ReadAll(bounded)
    if err != nil {
        return nil, err
    }
    if int64(len(body)) > limit {
        return nil, ErrDecodedBodyTooLarge
    }
    return body, nil
}

gzip.NewReader से पहले भी raw limit लगाएं। वह decoded limit की जगह नहीं लेती। वह peer को बहुत बड़ी compressed stream भेजने से रोकती है और यह भी सीमित करती है कि decoder को आगे बढ़ने लायक input मिलने से पहले क्लाइंट कितना काम स्वीकार करता है।

चुपचाप truncate करके आगे न बढ़ें। Truncated JSON document आम तौर पर parse नहीं होगा, लेकिन truncated text या line protocol विश्वसनीय लग सकता है। Diagnostics के लिए preview रखना हो तो उसे ऐसे field में preview के रूप में चिह्नित करें, जिसे पूरी body समझने की गलती न हो सके। कार्रवाई विफल होनी चाहिए, क्योंकि क्लाइंट को पूर्ण और अनुमत जवाब नहीं मिला।

Decoder को भ्रष्ट checksum केवल stream के अंत तक पहुंचकर पता चल सकता है। Decoded limit लगने पर पढ़ना रोकें और जवाब अस्वीकार करें। जिस oversized body को आप पहले ही फेंकने का निर्णय ले चुके हैं, उसकी जांच पूरी करने की जरूरत नहीं है। जवाब सीमा में रहे तो EOF तक पढ़ें और decoder को truncation या corruption सामान्य तरीके से बताने दें।

जवाब मेमोरी से पहले कॉन्टेक्स्ट खत्म कर सकता है

मेमोरी की सुरक्षा जरूरी है, लेकिन agent tools का एक और budget होता है: परिणाम का वह text जो सुरक्षित रूप से एजेंट बातचीत में आ सकता है। 2 MB का JSON जवाब desktop process के लिए हानिरहित हो सकता है, फिर भी tool result के रूप में बहुत खराब है। वह काम की बात को दबा सकता है, एजेंट को अप्रासंगिक records के पीछे भेज सकता है या model को अधूरे representation पर तर्क करने के लिए मजबूर कर सकता है जो पूरा दिखता है।

Context budget को decoded body limit बढ़ाने का कारण न बनाएं। वे अलग कार्यों की रक्षा करते हैं। Decoded limit transport और parser को सुरक्षित रूप से खत्म होने देती है। Presentation limit यह नियंत्रित करती है कि सफल decoding और, जहां उचित हो, structured parsing के बाद एजेंट को क्या मिलता है।

Structured data के लिए मनमाने bytes काटने के बजाय projection चुनें। Endpoint records की सूची लौटाए तो records की सीमित संख्या और हर field में सीमित text रखें। कुल record count तभी शामिल करें जब parser को पूरी सूची रखे बिना वह मिल गया हो। साफ बताएं कि परिणाम घटाया गया है और selection rule दें, जैसे «timestamp के क्रम में पहले 50 records»। इससे परिणाम का audit किया जा सकता है और एजेंट उसे पूरी खोज नहीं मानता।

Plain text में जहां संभव हो पूरी lines रखें। बीच line पर खत्म होने वाला log preview कम उपयोगी है और समझाने वाला field छिपा सकता है। Byte budget तय करें, line-length cap के साथ line by line पढ़ें और retained count व अतिरिक्त content हटाने का कारण, दोनों बताएं। अपनी token size limit के बिना line reader allocation की समस्या को बस दूसरे helper में भेज देता है।

यहीं «model इसे summarize कर सकता है» वाली सोच टूट जाती है। Model उस डेटा का सार बना सकता है जिसे आपने जानबूझकर चुना है। वह असीमित transport को सुरक्षित नहीं बना सकता और उसे यह तय नहीं करना चाहिए कि सीमा जांचने से पहले आपकी process remote output के लिए कितनी memory allocate करे।

Client contract में content coding साफ होनी चाहिए

Content-Encoding को अन्यथा समान byte stream की सजावट नहीं, बल्कि decoder चुनने वाले input की तरह लें। केवल वे encodings स्वीकार करें जिन्हें आपका client लागू करता है और अनजान values को साफ तौर पर अस्वीकार करें। Service gzip लौटाए तो gzip path इस्तेमाल करें। br लौटाए तो उसी decoded byte limiter में लिपटा Brotli decoder इस्तेमाल करें। Content coding न हो तो raw body को उसी decoded limiter में लपेटें, क्योंकि इस स्थिति में raw bytes ही decoded bytes हैं।

एक से अधिक content codings को यूं ही स्वीकार न करें। HTTP codings की सूची की अनुमति देता है और सूचीबद्ध transformations का क्रम होता है। gzip, br support करने का अर्थ है उलटे क्रम में decode करना और हर expansion stage के बाद size guard लगाना। केवल अंतिम limit दिखने से कमजोर होती है, क्योंकि अंतिम stage घटाने से पहले कोई intermediate stage बहुत बड़ा हो सकता है। Integrations को stacked codings की जरूरत न हो तो tests और जानबूझकर बनाई implementation तैयार होने तक उन्हें अस्वीकार करें।

Automatic decompression की जांच जरूरी है। कई HTTP libraries Accept-Encoding जोड़ती हैं, gzip decode करती हैं और application code से यह बदलाव छिपा देती हैं। सामान्य requests में यह सुविधाजनक है, लेकिन इससे code गलत layer पर bytes गिन सकता है। पता करें कि response body wire bytes देती है या decoded bytes, library Content-Encoding हटाती है या नहीं और compressed byte count उपलब्ध कराती है या नहीं। अपनी ठीक client configuration के व्यवहार को साबित करने वाला test लिखें।

Brotli को gzip जैसा ही व्यवहार चाहिए। हर environment में gzip command होने के कारण gzip test लिखकर काम पूरा मान लेना आसान है। अलग decoder का अर्थ अलग error handling, buffering behavior और dependency versions में अलग support है। Limit हर decoder के लौटाए reader के आसपास होनी चाहिए, केवल उस helper में नहीं जिसे संयोग से सिर्फ gzip route बुलाता है।

सर्वर घोषित encoding के साथ invalid body भी भेज सकता है। इसे decoding error ही रखें, oversized decoded response से अलग। Operators को पता होना चाहिए कि remote side ने खराब data भेजा, configured budget कम था या client में घोषित coding का decoder नहीं है।

ऐसे files से expansion जांचें जिन्हें आप देख सकें

उपयोगी fixture की शुरुआत ऐसे decoded content से होती है जिसे आप पहचान और माप सकें। Repeated bytes स्पष्ट expansion case देते हैं। ये commands 32 MiB की text body बनाते हैं, फिर Brotli command installed होने पर gzip और Brotli versions बनाते हैं।

python3 -c 'open("repeat.txt", "wb").write(b"A" * (32 * 1024 * 1024))'
wc -c repeat.txt
gzip -9 -c repeat.txt > repeat.txt.gz
brotli -f repeat.txt -o repeat.txt.br
wc -c repeat.txt.gz repeat.txt.br

पहले wc output का रूप 33554432 repeat.txt होना चाहिए। Input में एक ही byte दोहराने के कारण compressed files source से बहुत छोटी होनी चाहिए। Test में किसी खास compressed size की अपेक्षा न रखें। Compression versions और settings उसे बदल सकते हैं। Decoded length, client outcome और अस्वीकार करने के बाद client ने पूरी body retain नहीं की, इन बातों की जांच करें।

उसी source से boundary cases बनाएं: configured limit से एक byte कम decoded body, ठीक limit पर body और उससे एक byte अधिक body। हर case को ऐसे local HTTP handler से चलाएं जो Content-Encoding सही सेट करता हो। File decoder test उपयोगी है, लेकिन वह ऐसी client library नहीं पकड़ सकता जो आपकी limit code चलने से पहले automatic decompression कर देती है।

यथार्थवादी structure वाले fixtures का दूसरा परिवार रखें। Newline-delimited JSON बनाएं, जिसमें हर record में repeated payload field हो, फिर उसे gzip और Brotli के साथ serve करें। इससे वह code पकड़ा जाता है जो byte slice को सही संभालता है, लेकिन decoding के बाद JSON parser या line scanner को असीमित array बनाने देता है। अपनी field या line limit से लंबा एक record भी रखें, क्योंकि parser से allocation करवाने के लिए attacker को छोटी lines दोहराने की जरूरत नहीं होती।

Fixtures तभी repository में रखें जब उनके compressed forms छोटे हों और source tests के दौरान बनाया जा सकता हो। ज्ञात decoded length देने वाली generator script की समीक्षा रहस्यमय binary blob से आसान है। Intended decoded size को केवल उस comment में न लिखें जो boundary fail होने पर कोई नहीं देखता, test name में भी लिखें।

विफलता अक्सर सहायक convenience method से शुरू होती है

ऐसे agent पर विचार करें जो issue data के लिए API बुलाता है। Endpoint आम तौर पर छोटा JSON page लौटाता है। Client Accept-Encoding: gzip भेजता है, ऐसी response पाता है जिसका Content-Length 18 KB है और इसे result के सीमित होने के प्रमाण की तरह log करता है। फिर उसका HTTP helper body को पारदर्शी रूप से decompress करता है और JSON parsing से पहले ReadAll बुलाता है।

खराब upstream response में हर record के भीतर बड़ा, बार-बार दोहराया गया description field है। 18 KB transfer सामान्य page से कहीं अधिक data में फैलता है। Process byte slice allocate करती है, parsing के दौरान strings और maps बनाती है, फिर एजेंट के लिए चुने records serialize करती है। Request के कम से कम कुछ हिस्से में हर stage अलग copy रखता है। Parsing के बाद लगाई limit समस्या को केवल महंगा काम हो जाने के बाद देखती है।

पहला सुधार अक्सर ReadAll के बाद if len(body) > limit जोड़ता है। इससे unit test हरा दिखता है, लेकिन allocation spike बनी रहती है। दूसरा सुधार decoded reader को wrap करता है, जो सही दिशा है, लेकिन fallback के रूप में पहले limit bytes एजेंट को भेजता है। अब एजेंट आधे जवाब के आधार पर कार्रवाई कर सकता है और audit trail साफ विफलता नहीं दिखाता।

पूरा सुधार decoded reader पर जल्दी अस्वीकार करता है, partial content फेंकता है, encoding और byte budget दर्ज करता है और caller को वर्गीकृत की जा सकने वाली error देता है। Endpoint को सच में बड़े exports चाहिए हों तो उस use case को अधिक मंजूर सीमा, user द्वारा चुने destination और agent context में file के स्वत: प्रवेश के बिना, स्पष्ट download path में ले जाएं।

यह विभाजन जरूरी है, क्योंकि report download और agent tool lookup अलग operations हैं। दोनों को HTTP request कहना उनके risk या budget को एक जैसा नहीं बनाता।

Limits का endpoint owner और कारण होना चाहिए

Global default शुरुआत है, हर HTTP action के लिए उपयुक्त policy नहीं। Decoded response limit को endpoint के अपेक्षित result के अनुसार तय करें। Status check को केवल कुछ kilobytes चाहिए हो सकते हैं। Paginated search मध्यम आकार का structured response लौटा सकती है। Binary export को बड़ी bound चाहिए हो सकती है, पर उसे conversational result की जगह file path में जाना चाहिए।

Limit को उसके कारण के साथ action definition के पास लिखें। «API documentation कहता है कि page size 100 है» पर्याप्त कारण नहीं, क्योंकि एक record भी बहुत बड़ा हो सकता है। उपयोगी कारण अपेक्षित representation और caller का उपयोग बताता है, जैसे «एक status object parse करके चुने हुए fields लौटाएं» या «स्पष्ट मंजूरी के बाद user द्वारा मांगा archive save करें»।

Cap केवल server-supplied page-size parameter से न निकालें। Server parameter को अनदेखा कर सकता है, agent बहुत व्यापक query मांग सकता है और एक text field पूरे response पर हावी हो सकता है। जहां हर boundary पर समझ बने, वहां page size, query breadth, decoded bytes, parsed records और agent result bytes सीमित करें। ये controls जानबूझकर overlap करते हैं, क्योंकि हर एक अलग तरह के खराब request या response को पकड़ता है।

Response अस्वीकार करते समय diagnosis के लिए पर्याप्त विवरण दर्ज करें: HTTP method, host या action identifier, उपलब्ध हो तो status code, घोषित content encoding, देखे गए compressed bytes, decoded limit और decoder ने output देना शुरू किया था या नहीं। अस्वीकार की गई body को default रूप से दर्ज न करें। ऐसा logging supposedly diagnostic path में फिर वही memory और sensitive-data समस्या बना सकता है।

मानव की मंजूरी response को हानिरहित नहीं बनाती। मंजूरी remote service के साथ कार्रवाई की अनुमति दे सकती है, लेकिन वह नहीं बता सकती कि service कितना data लौटाएगी। मंजूरी के बाद और एजेंट को data मिलने से पहले response bounds लागू रखें।

Cancellation और timeouts अलग विफलता से बचाते हैं

Decoded size cap, decoder के पर्याप्त output देने के बाद वृद्धि रोकती है। वह ऐसे peer को नहीं रोकती जो बहुत धीमे bytes भेजे, crafted stream पर जरूरत से अधिक CPU लेने वाले decoder को नहीं रोकती और न कभी पूरा न होने वाले response को। Request deadlines तय करें और सुनिश्चित करें कि cancellation response body बंद करती है और reader को रोकती है।

Metrics और errors में time, compressed bytes, decoded bytes और parsed item counts अलग रखें। सभी विफलताएं «request failed» दिखेंगी तो कोई timeout ठीक करने के लिए size limit बढ़ाएगा या parser failure ठीक करने के लिए timeout बढ़ाएगा। ऐसे बदलाव diagnosis कठिन बनाते हैं और अक्सर attack surface बढ़ाते हैं।

ऐसे endpoint के सामने cancellation जांचें जो valid compressed prefix भेजकर रुक जाता है। Client को decoder पर goroutine प्रतीक्षा में रखे बिना timeout या cancellation error लौटानी चाहिए। फिर ऐसी body जांचें जो decoded cap के पार तेजी से फैलती है। Server compressed bytes भेजता रहे तब भी इस path को शीघ्र size error देना चाहिए।

Early rejection के बाद connection reuse में सावधानी चाहिए। कई clients में resources छोड़ने के लिए body बंद करना पर्याप्त है, लेकिन client ने बाकी response consume नहीं किया तो connection reuse योग्य नहीं रह सकती। यह स्वीकार्य है। Hostile या खराब response से एक और keep-alive connection निकालने से correctness और bounded resource use अधिक महत्वपूर्ण हैं।

Oversized response को अपने आप retry न करें। Bounded policy के भीतर transient network error retry का कारण बन सकती है। ज्ञात limit से अधिक response आम तौर पर deterministic होता है। इसे दोहराना bandwidth बर्बाद करता है और ऐसे process पर दबाव बढ़ा सकता है जो पहले ही oversized action से जूझ रही है।

Parse limits decode के बाद की हैं, उनकी जगह नहीं

Streaming JSON parser आपको हर record store करने से रोक सकता है, लेकिन decoded byte cap खत्म नहीं करता। Parsers को फिर भी buffers चाहिए, अलग-अलग strings बहुत बड़ी हो सकती हैं और error reporting source fragments रख सकती है। Parser से पहले byte cap लगाएं, फिर स्वीकार किए जाने वाले data से मेल खाती format limits जोड़ें।

JSON के लिए maximum nesting depth, maximum string length, maximum record count और एजेंट जिन fields का उपयोग करेगा उनके लिए strict schema पर विचार करें। CSV या line protocols के लिए maximum line length और maximum row count तय करें। XML में external entity processing बंद करें और जहां library दे वहां parser limits लगाएं। ये parsing rules हैं, जबकि decoded body cap transport boundary है। एक को दूसरे का रूप लेने के लिए मजबूर न करें।

Render करने से पहले validate करें। Remote service से आया instructions, command या message नाम का field फिर भी remote content है। उसका आकार decoded cap में हो सकता है, फिर भी उसे agent के control flow में रखना अनुचित हो सकता है। Fields को schema के अनुसार चुनें और उन्हें data के रूप में encode करें। Size limit एक तरह की विफलता रोकती है, bytes की बात पर भरोसा नहीं बनाती।

इस अलगाव से error handling कम उलझती है। Decoded limit पार करने वाली body parser तक कभी नहीं जानी चाहिए। सीमा में रहने पर भी बहुत अधिक records वाली body parsing या application limit error लौटाए। Schema में फिट होने पर भी agent presentation budget से अधिक body को स्पष्ट result rule से कम किया जाए। हर outcome operator को बताता है कि कुछ बदलना है या नहीं और क्या बदलना है।

Audit record को boundary report समझें

उपयोगी audit entry बताती है कि process ने क्या कोशिश की और client ने आगे बढ़ने से क्यों मना किया। उसमें अस्वीकार किया गया content होना जरूरी नहीं। Action identity, authorization context, destination, request time, उपलब्ध होने पर response status, encoding, wire byte count, decoded byte count या उसकी lower bound और call रोकने वाली limit store करें।

Early rejection में decoded count वास्तविक अंतिम आकार के बजाय limit + 1 हो सकती है, क्योंकि client ने जानबूझकर पढ़ना रोक दिया। इसे ईमानदारी से दर्ज करें। पूरा decoded size जानने का दावा यह संकेत देता है कि आपने उसी stream को consume किया जिसे सीमित रखना था। निर्णय समझाने के लिए lower bound पर्याप्त है।

यह खास तौर पर तब उपयोगी है जब operator के query बदलने पर agent कार्रवाई दोहराता है। आप देख सकते हैं कि पहली call presentation या decoded budget से अधिक थी और दूसरी संकरी request के साथ सफल रही। इस अंतर के बिना failed tool call authentication या network problem से अलग नहीं दिखती और लोग गलत समाधान अपनाते हैं।

Sallyport की activity trail कार्रवाई के result path को सुरक्षित रख सकती है, बिना एजेंट को API credential दिए। फिर भी caller को oversized result को bounded failure के रूप में report करना होगा, activity record को response की दूसरी copy में नहीं बदलना होगा।

Oversized case को release gate का हिस्सा बनाएं

Decompression checks को ऐसा security test न रहने दें जो केवल किसी को याद आने पर चले। सामान्य client test suite में gzip और Brotli boundary fixture रखें। हर HTTP code path से वही assertions चलाएं जो agent को data लौटा सकता है, जिनमें redirects शामिल हैं यदि client उन्हें follow करता है और error responses भी यदि diagnostics के लिए उनकी bodies पढ़ी जाती हैं।

Assertions ठोस होने चाहिए। Limit से कम body के लिए complete decoded result और successful checksum validation अपेक्षित रखें। ठीक limit पर भी वही अपेक्षा रखें। एक byte अधिक पर typed size error, कोई parsed object नहीं, कोई agent result नहीं और बंद response body अपेक्षित रखें। Malformed encoding पर decoding error और unsupported encoding पर parsing शुरू होने से पहले साफ unsupported-encoding error अपेक्षित रखें।

ऐसी compressed body का test जोड़ें जिसका wire size छोटा हो और decoded size cap से अधिक हो। वही test शुरुआती गलती पकड़ता है। बड़ी uncompressed body केवल यह साबित करती है कि सामान्य byte limiter काम करता है। वह decoder boundary के बारे में कुछ नहीं कहती।

हर उस बदलाव की समीक्षा करें जो नई HTTP library, नई convenience fetch helper या नया response logging path लाता है। ये बदलाव अक्सर ध्यान से सीमित reader को bypass कर देते हैं, क्योंकि अलग से देखने पर वे हानिरहित लगते हैं। Code review का सवाल सरल है: decoded bytes पहली बार कहां उपलब्ध होते हैं और उस ठीक reader के चारों ओर कौन सी limit है?

यदि जवाब स्पष्ट नहीं है, तो implementation autonomous caller के लिए तैयार नहीं है। Network पर छोटा जवाब कोई विशेष भरोसा नहीं कमाता। Decode होने के बाद उसका आकार साबित करने दें, इससे पहले कि उसे आपकी memory या एजेंट का ध्यान खर्च करने का मौका मिले।