Ser Requests-svaret förvrängt ut bakom en proxy? Kontrollera Brotli-stödet
En kopierad Accept-Encoding:br kan springa om dekoderstödet i den värdbaserade Requests-miljön.
Jämför den bärbara datorn och den värdbaserade processen på två olika lager:
| Lager | Fråga |
|---|---|
| Content-Encoding | Kan klienten dekomprimera de returnerade gzip/deflate/Brotli-byten? |
| Charset | Hur blir dekomprimerade byten text? |
Requests hanterar normalt gzip/deflate; Brotli kräver ett installerat bibliotek med stöd. En manuellt kopierad Accept-Encoding kan annonsera br när den här miljön inte kan avkoda det. Val av UTF-8-text dekomprimerar inte Brotli.
När förhandlingen medvetet begränsas:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Använd den befintliga Session, HTTPS-URL:en och de obligatoriska rubrikerna/autentiseringen. Jämför utgående Accept-Encoding, inkommande Content-Encoding och paketstöd på båda maskinerna; en transformerande mellanhand kan också leverera inaktuell metadata. En separat jämförelse av en offentlig sida kan använda Lista över HTTP-proxyer för sin proxy-URL där offentliga mellanhänder är tillåtna, utan ärvda proxyuppgifter, kopierade kontorubriker eller privata kroppsdata.
Annars föredra normal klientförhandling. Requests bekväma content/text-gränssnitt avkodar kodning som stöds, så dekomprimera inte deras utdata igen bara för att rubriken namnger den.