بایت‌های 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 خروجی پاسخ موجود است. وضعیت و سرصفحه‌های آن باید از پیش از سیاست انتخاب‌شده پیروی کنند؛ این قطعه یک سرور پروکسی کامل را پیاده‌سازی نمی‌کند.

چارچوب‌بندی انتقال از کدگذاری content gzip جداست. کتابخانه HTTP بالادست چارچوب‌بندی را از قبل انجام داده است، از جمله حذف قطعه‌ها، پس Transfer-Encoding را کورکورانه کپی نکنید. سرور پایین‌دست پاسخ خودش را چارچوب‌بندی می‌کند حتی وقتی بار کدشده با gzip باقی می‌ماند.

response.text به‌همراه کدگذاری UTF-8 نیز نمایش را تغییر می‌دهد و نمی‌تواند داده‌های دودویی دلخواه را حفظ کند. پاسخ بالادست را در هر مسیر ببندید یا مصرف کنید و خطاهای HTTP را مطابق قرارداد پروکسی مدیریت کنید: این مثال آن‌ها را به‌جای ارسال، پرتاب می‌کند.