Odpověď Requests vypadá za proxy poškozená? Zkontrolujte podporu Brotli
Zkopírovaný Accept-Encoding:br může předběhnout podporu dekodéru v hostovaném prostředí Requests.
Porovnejte notebook a hostovaný proces ve dvou různých vrstvách:
| Vrstva | Otázka |
|---|---|
| Content-Encoding | Dokáže klient dekomprimovat vrácené bajty gzip/deflate/Brotli? |
| Charset | Jak se dekomprimované bajty stanou textem? |
Requests obvykle zvládá gzip/deflate; Brotli vyžaduje nainstalovanou podporovanou knihovnu. Ručně zkopírovaný Accept-Encoding může inzerovat br, i když toto prostředí neumí dekódovat. Volba textu UTF-8 Brotli nedekomprimuje.
Když záměrně omezujete vyjednávání:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Použijte stávající Session, HTTPS URL a požadované hlavičky/autentizaci. Porovnejte odchozí Accept-Encoding, příchozí Content-Encoding a podporu balíčků na obou strojích; transformující prostředník může také dodat zastaralá metadata. Samostatné srovnání veřejné stránky může použít Seznam HTTP proxy pro svou URL proxy tam, kde jsou veřejní prostředníci povoleni, bez zděděných přihlašovacích údajů proxy, zkopírovaných hlaviček účtu nebo soukromých dat těla.
Jinak dejte přednost běžnému vyjednávání klienta. Pohodlná rozhraní content/text v Requests dekódují podporované kódování, takže jejich výstup znovu nedekomprimujte jen proto, že ho hlavička pojmenovává.