Якщо Requests уже розпакував тіло, передавання його з Content-Encoding: gzip просить наступного клієнта розпакувати його знову. Вирішіть, яке подання навантаження надсилає проксі, перш ніж копіювати заголовки.

Надіслане навантаженняContent-заголовки
Оригінальні кодовані байтиЗбережіть застосовне кодування та точну довжину навантаження
Декодовані байтиВидаліть декодоване кодування; видаліть або перерахуйте відповідну довжину

Для кодованих байтів навантаження цей фрагмент читає необроблений потік 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 згідно з контрактом проксі: цей приклад викидає їх замість передавання.

Схожі статті