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 त्रुटियाँ संभालें: यह उदाहरण उन्हें अग्रेषित करने के बजाय फेंकता है।