जब डाउनलोड गरिएको फाइल HTTP स्थिति लाइनबाट सुरु हुन्छ

यदि PDF वा स्प्रेडसिट जस्तो देखिने फाइल HTTP/1.1 200 OK बाट सुरु हुन्छ भने, डाउनलोडरले फाइलको सट्टा कच्चा प्रतिक्रिया सुरक्षित गरेको छ। यो योजनाबद्ध प्रतिक्रियामा चार बाइट सामग्री मात्र छ:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

फाइल DATA हो। स्थिति लाइन, हेडरहरू, आकार मार्कर र अन्त्य संरचना HTTP का हुन्। हेडरको लम्बाइ फरक हुने भएकाले निश्चित संख्याको बाइट हटाउनु सुरक्षित छैन। पहिलो खाली लाइनपछिको सबै प्रतिलिपि गर्दा पनि चंक फ्रेमिङ रहन्छ, र सूचनात्मक प्रतिक्रियाहरू अन्तिम प्रतिक्रियाअघि आउन सक्छन्।

सामान्य डाउनलोडका लागि, कच्चा सकेटबाट फाइलमा प्रतिलिपि गर्ने कामलाई HTTP क्लाइन्टको प्रतिक्रिया-बडी इन्टरफेसले प्रतिस्थापन गर्नुहोस्। यसको प्रोक्सी कन्फिगर गर्नुहोस्, अन्तिम स्थिति प्रमाणित गर्नुहोस् र बडीलाई अस्थायी आउटपुटमा स्ट्रिम गर्नुहोस्। क्लाइन्टले सन्देश फ्रेमिङ ह्यान्डल गर्छ: लम्बाइद्वारा सीमित, चंक गरिएको र जडानद्वारा सीमित बडीलाई फरक पार्सिङ चाहिन्छ।

सामग्री इन्कोडिङ अर्को तह हो। क्लाइन्टको कागजात गरिएको व्यवहार प्रयोग गरेर तपाईंलाई डिकोड गरिएका फाइल बाइट चाहिन्छ वा स्पष्ट रूपमा अनुरोध गरिएको कच्चा सामग्री भनेर निर्णय गर्नुहोस्। कम्प्रेस गरिएका बाइटहरू स्वतः प्रोक्सी बिग्रिएको हुँदैनन्।

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

HTTPS लाई CONNECT प्रतिक्रिया हटाउनुभन्दा बढी चाहिन्छ: सुरुङ सफलतापूर्वक स्थापना भएपछि, गन्तव्य TLS स्थापना गर्नुहोस् र त्यसपछि भित्री HTTP प्रतिक्रिया पार्स गर्नुहोस्। प्रोक्सीका हेडरपछिका इन्क्रिप्टेड बाइटहरू डाउनलोड गर्न मिल्ने फाइल होइनन्।

असफल वा अपूर्ण आउटपुट अस्थायी नाममा राख्नुहोस्। स्थानान्तरण र फाइल जाँचहरू सफल भएपछि मात्र यसलाई प्रकाशित गर्नुहोस्; खाली नभएको फाइलले पूरा डाउनलोड प्रमाणित गर्दैन।