अपलोड को टुकड़ों में पढ़ने के लिए chunked HTTP की आवश्यकता नहीं है

नहीं। कोई क्लाइंट बड़ी फ़ाइल को छोटे बफ़रों में पढ़कर ज्ञात Content-Length के साथ भेज सकता है। सीमित रीड मेमोरी के उपयोग को नियंत्रित करती हैं; HTTP फ़्रेमिंग प्राप्तकर्ता को बताती है कि अनुरोध का body कहाँ समाप्त होता है।

ऐसी स्थिर फ़ाइल जिसकी बाइट-लंबाई HTTP लाइब्रेरी जानती है, अज्ञात मात्रा में डेटा बनाने वाले जनरेटर से अलग होती है। दोनों स्रोतों के लिए लाइब्रेरी द्वारा समर्थित body इंटरफ़ेस का उपयोग करें। केवल लंबाई देने के लिए पूरी फ़ाइल को एक string में जोड़ने की ज़रूरत नहीं है।

HTTP/1.1 के लिए, प्रोटोकॉल के नियमों के अनुसार वास्तव में भेजी गई फ़्रेमिंग जाँचें: Content-Length या chunked ट्रांसफ़र कोडिंग। Chunked कोडिंग फ़ाइल की सामग्री के बाहर आकार के चिह्न जोड़ती है। परस्पर विरोधी फ़्रेमिंग फ़ील्ड मत मिलाएँ और प्रॉक्सी को अपलोड स्वीकार करने के लिए लंबाई का अनुमान मत लगाएँ।

अगर प्रॉक्सी के ज़रिए अपलोड विफल हो, तो HTTP संस्करण, body का स्रोत और पहला अस्वीकरण दर्ज करें। 411 प्रतिक्रिया body के बीच में बंद होने वाले कनेक्शन से भिन्न जाँच का संकेत देती है। अगर इसके बजाय प्रमाणीकरण के पुनः प्रयास विफल हों, तो देखें क्या अपलोड body दोबारा चलाया जा सकता है। ऐप्लिकेशन के read-buffer का आकार बदलने से अनुरोध की फ़्रेमिंग पहले जैसी ही रह सकती है।

उस अवलोकन के लिए मार्ग महत्वपूर्ण है। सादा-पाठ अग्रेषण अपलोड की HTTP फ़्रेमिंग को प्रॉक्सी के सामने उजागर करता है; सामान्य एंड-टू-एंड HTTPS उसे सुरंग के भीतर रखता है। HTTP/2 अपनी स्वयं की फ़्रेमिंग का उपयोग करता है। इसलिए ऐतिहासिक Squid सीमाएँ कुछ विशेष पुरानी विफलताएँ समझाती हैं, यह नियम नहीं कि हर आज का प्रॉक्सी स्ट्रीम किए गए अपलोड अस्वीकार करता है।