अपलोड तुकड्यांमध्ये वाचण्यासाठी chunked HTTP आवश्यक नाही

नाही. क्लायंट मोठी फाइल लहान बफरमध्ये वाचून ज्ञात Content-Length सह पाठवू शकतो. मर्यादित वाचने स्मृतीचा वापर नियंत्रित करतात; HTTP फ्रेमिंग प्राप्तकर्त्याला सांगते की विनंतीचा बॉडी कुठे संपतो.

HTTP लायब्ररीला ज्याची बाइट-लांबी माहीत आहे अशी स्थिर फाइल अज्ञात प्रमाणात डेटा तयार करणाऱ्या जनरेटरपेक्षा वेगळी असते. दोन्ही स्रोतांसाठी लायब्ररीने समर्थित बॉडी इंटरफेस वापरा. फक्त लांबी देण्यासाठी संपूर्ण फाइल स्ट्रिंगमध्ये जोडण्याची गरज नाही.

HTTP/1.1 साठी, प्रोटोकॉलच्या नियमांनुसार प्रत्यक्ष पाठवलेले फ्रेमिंग तपासा: Content-Length किंवा chunked ट्रान्सफर कोडिंग. Chunked कोडिंग फाइलच्या सामग्रीबाहेर आकाराच्या खुणा जोडते. परस्परविरोधी फ्रेमिंग फील्ड एकत्र करू नका आणि प्रॉक्सीला अपलोड स्वीकारण्यास भाग पाडण्यासाठी लांबीचा अंदाज लावू नका.

प्रॉक्सीमधून जाणारे अपलोड अयशस्वी झाल्यास HTTP आवृत्ती, बॉडीचा स्रोत आणि पहिले नकार नोंदवा. 411 प्रतिसाद बॉडीच्या मध्यभागी बंद होणाऱ्या कनेक्शनपेक्षा वेगळ्या तपासणीकडे निर्देश करतो. त्याऐवजी प्रमाणीकरणाचे पुनःप्रयत्न अयशस्वी झाल्यास, अपलोडचा बॉडी पुन्हा चालवता येतो का ते पाहा. अनुप्रयोगाच्या रीड-बफरचा आकार बदलल्याने विनंतीचे फ्रेमिंग पूर्वीप्रमाणेच राहू शकते.

त्या निरीक्षणासाठी मार्ग महत्त्वाचा आहे. स्पष्ट-मजकूर अग्रेषण अपलोडचे HTTP फ्रेमिंग प्रॉक्सीसमोर उघड करते; सामान्य एंड-टू-एंड HTTPS ते बोगद्यात ठेवते. HTTP/2 स्वतःचे फ्रेमिंग वापरते. म्हणून ऐतिहासिक Squid मर्यादा विशिष्ट जुन्या अपयशांची मांडणी करतात, आजचा प्रत्येक प्रॉक्सी स्ट्रीम केलेले अपलोड नाकारतो असा नियम नाही.