जेव्हा डाउनलोड केलेली फाईल HTTP स्थिती ओळीने सुरू होते

जर एखादी PDF किंवा स्प्रेडशीट असल्याचे वाटणारी फाईल HTTP/1.1 200 OK ने सुरू होत असेल, तर डाउनलोडरने फाईलऐवजी कच्चा प्रतिसाद जतन केला आहे. या योजनाबद्ध प्रतिसादात फक्त चार बाइट सामग्री आहे:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

फाईल DATA आहे. स्थिती ओळ, हेडर, आकाराचा मार्कर आणि समाप्ती रचना HTTP ची आहेत. हेडरची लांबी बदलत असल्याने ठराविक बाइट काढणे सुरक्षित नाही. पहिल्या रिकाम्या ओळीनंतर सर्वकाही कॉपी केल्यावरही तुकडा फ्रेमिंग राहते, आणि माहितीपर प्रतिसाद अंतिम प्रतिसादापूर्वी येऊ शकतात.

सामान्य डाउनलोडसाठी, कच्च्या सॉकेटपासून फाईलमध्ये कॉपी करणे हे HTTP क्लायंटच्या प्रतिसाद-बॉडी इंटरफेसने बदला. त्याचा प्रॉक्सी कॉन्फिगर करा, अंतिम स्थिती तपासा आणि बॉडी तात्पुरत्या आउटपुटमध्ये स्ट्रीम करा. क्लायंट संदेशाची फ्रेमिंग हाताळतो: लांबीने मर्यादित, तुकड्यांमध्ये (chunked) आणि कनेक्शनने मर्यादित बॉडींना वेगळे पार्सिंग लागते.

सामग्री एन्कोडिंग हा अजून एक थर आहे. क्लायंटच्या दस्तऐवजीकृत वर्तनाचा वापर करून तुम्हाला डीकोड केलेले फाईल बाइट हवे आहेत की स्पष्टपणे मागितलेली कच्ची सामग्री हे ठरवा. संकुचित बाइट स्वयंचलितपणे प्रॉक्सीचे नुकसान नसतात.

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

HTTPS ला CONNECT प्रतिसाद काढण्यापेक्षा अधिक लागते: टनेल यशस्वीरित्या स्थापित केल्यानंतर, गंतव्य TLS प्रस्थापित करा आणि नंतर आतील HTTP प्रतिसाद पार्स करा. प्रॉक्सीच्या हेडरनंतरचे एन्क्रिप्टेड बाइट ही डाउनलोड करण्यायोग्य फाईल नाही.

अयशस्वी किंवा अपूर्ण आउटपुट तात्पुरत्या नावाखाली ठेवा. हस्तांतरण आणि फाईल तपासण्या यशस्वी झाल्यानंतरच ते प्रकाशित करा; रिकामी नसलेली फाईल पूर्ण डाउनलोड सिद्ध करत नाही.