Ser Requests-svaret forvrengt ut bak ein proxy? Sjekk Brotli-støtta
Ein kopiert Accept-Encoding:br kan gå forbi dekodarstøtta i det hosta Requests-miljøet.
Samanlikn den berbare maskina og den hosta prosessen på to ulike lag:
| Lag | Spørsmål |
|---|---|
| Content-Encoding | Kan klienten dekomprimere dei returnerte gzip/deflate/Brotli-byta? |
| Charset | Korleis blir dekomprimerte byte til tekst? |
Requests handterer vanlegvis gzip/deflate; Brotli krev eit støtta installert bibliotek. Ein manuelt kopiert Accept-Encoding kan annonsere br når dette miljøet ikkje kan dekode det. Val av UTF-8-tekst dekomprimerer ikkje Brotli.
Når forhandlinga med vilje blir avgrensa:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Bruk den eksisterande Session, HTTPS-URL-en og dei kravde headera/autentiseringa. Samanlikn utgåande Accept-Encoding, innkomande Content-Encoding og pakkestøtte på begge maskinene; ein transformerande mellommann kan òg levere utdatert metadata. Ei separat samanlikning av ei offentleg side kan bruke Liste over HTTP-proxyar til proxy-URL-en der offentlege mellomledd er tillatne, utan arva proxy-legitimasjon, kopierte kontoheadera eller private kroppsdata.
Elles bør du føretrekkje normal klientforhandling. Dei praktiske content/text-grensesnitta i Requests dekodar støtta koding, så ikkje dekomprimer utdataa deira igjen berre fordi headeren nemner det.