अपलोडलाई टुक्राटुक्रामा पढ्न chunked HTTP आवश्यक पर्दैन

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

HTTP लाइब्रेरीले जसको बाइट-लम्बाइ जान्दछ त्यस्तो स्थिर फाइल अज्ञात मात्रामा डेटा उत्पादन गर्ने जेनेरेटरभन्दा फरक हुन्छ। दुवै स्रोतका लागि लाइब्रेरीले समर्थन गर्ने बडी इन्टरफेस प्रयोग गर्नुहोस्। केवल लम्बाइ दिन मात्र पूरै फाइल स्ट्रिङमा जोड्नु आवश्यक छैन।

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

प्रोक्सीमार्फत अपलोड असफल भएमा HTTP संस्करण, बडीको स्रोत र पहिलो अस्वीकृति रेकर्ड गर्नुहोस्। 411 प्रतिक्रियाले बडीको बीचमा बन्द हुने जडानभन्दा फरक अनुसन्धान संकेत गर्छ। यदि यसको सट्टा प्रमाणीकरणका पुनःप्रयास असफल भए, अपलोडको बडी पुनः चलाउन सकिन्छ कि जाँच्नुहोस्। एप्लिकेसनको रिड-बफरको आकार बदल्दा अनुरोधको फ्रेमिङ पहिलेजस्तै रहन सक्छ।

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