gzip बाइटहरूलाई तिनलाई वर्णन गर्ने हेडरसँगै अगाडि पठाउनुहोस्

यदि Requests ले पहिले नै बडी डिकम्प्रेस गरिसकेको छ भने, Content-Encoding: gzip सहित अगाडि पठाउँदा अर्को क्लाइन्टलाई यसलाई फेरि डिकम्प्रेस गर्न भनिन्छ। हेडर प्रतिलिपि गर्नु अघि प्रोक्सीले कुन पेलोड प्रतिनिधित्व पठाउँछ भनेर निर्णय गर्नुहोस्।

इन्कोड गरिएका पेलोड बाइटहरूका लागि, यो अंशले urllib3 को कच्चा स्ट्रिम content डिकोडिङ बिना पढ्छ:

with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
    upstream.raise_for_status()
    for block in upstream.raw.stream(65536, decode_content=False):
        downstream.write(block)

downstream अवस्थित प्रतिक्रिया आउटपुट हो। यसको स्थिति र हेडरहरूले पहिले नै छानिएको नीति पालना गर्नुपर्छ; यो अंशले पूर्ण प्रोक्सी सर्भर लागू गर्दैन।

ट्रान्सफर फ्रेमिङ gzip content इन्कोडिङबाट अलग छ। अपस्ट्रिम HTTP लाइब्रेरीले चङ्क हटाउने सहित फ्रेमिङ पहिले नै ह्यान्डल गरिसकेको छ, त्यसैले Transfer-Encoding लाई आँखा चिम्लेर प्रतिलिपि नगर्नुहोस्। पेलोड gzip-इन्कोड गरिएको रहे पनि डाउनस्ट्रिम सर्भरले आफ्नै प्रतिक्रिया फ्रेम गर्छ।

response.text पछि UTF-8 इन्कोडिङ गर्दा पनि प्रतिनिधित्व बदलिन्छ र मनपरी बाइनरी डेटा सुरक्षित राख्न सक्दैन। प्रत्येक मार्गमा अपस्ट्रिम प्रतिक्रिया बन्द गर्नुहोस् वा उपभोग गर्नुहोस्, र प्रोक्सी सम्झौता अनुसार HTTP त्रुटिहरू ह्यान्डल गर्नुहोस्: यो उदाहरणले तिनलाई अगाडि पठाउनुको सट्टा फ्याँक्छ।