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 غلطیاں سنبھالیں: یہ مثال انہیں آگے بھیجنے کے بجائے پھینکتی ہے۔