Отговорът на 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 декодират поддържаното кодиране, затова не разкомпресирайте изхода им отново само защото заглавката го назовава.