जब डाउनलोड की गई फ़ाइल 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 प्रतिक्रिया पार्स करें। प्रॉक्सी के हेडर के बाद आने वाले एन्क्रिप्टेड बाइट डाउनलोड योग्य फ़ाइल नहीं हैं।

असफल या अपूर्ण आउटपुट को अस्थायी नाम के अंतर्गत रखें। स्थानांतरण और फ़ाइल जाँच सफल होने के बाद ही उसे प्रकाशित करें; खाली न होने वाली फ़ाइल पूर्ण डाउनलोड सिद्ध नहीं करती।