Передавайте байти gzip із заголовками, що їх описують
Виберіть кодоване або декодоване корисне навантаження в проксі на основі Requests, потім надайте низхідній відповіді відповідні content-заголовки та власне кадрування.
Якщо 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 згідно з контрактом проксі: цей приклад викидає їх замість передавання.