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 त्रुटी हाताळा: हे उदाहरण त्यांना पुढे पाठवण्याऐवजी फेकते.