Відповідь Requests виглядає спотвореною за проксі? Перевірте підтримку Brotli
Скопійований Accept-Encoding:br може випереджати підтримку декодера в хостинговому середовищі Requests.
Порівняйте ноутбук і хостинговий процес на двох різних рівнях:
| Рівень | Питання |
|---|---|
| Content-Encoding | Чи може клієнт розпакувати повернуті байти gzip/deflate/Brotli? |
| Charset | Як розпаковані байти стають текстом? |
Requests зазвичай обробляє gzip/deflate; Brotli потребує встановленої підтримуваної бібліотеки. Скопійований вручну Accept-Encoding може оголошувати br, хоча це середовище не може його декодувати. Вибір тексту UTF-8 не розпаковує Brotli.
Коли переговори навмисно обмежують:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Використовуйте наявний Session, HTTPS-URL і потрібні заголовки/автентифікацію. Порівняйте вихідний Accept-Encoding, вхідний Content-Encoding і підтримку пакетів на обох машинах; перетворювальний посередник теж може подавати застарілі метадані. Окреме порівняння публічної сторінки може використовувати Список HTTP-проксі для адреси проксі там, де публічні посередники дозволені, без успадкованих облікових даних проксі, скопійованих заголовків акаунта чи приватних даних тіла.
Інакше надавайте перевагу звичайним переговорам клієнта. Зручні інтерфейси content/text у Requests декодують підтримуване кодування, тому не розпаковуйте їхній вивід повторно лише через те, що заголовок його називає.