Ser Requests-svaret forvrengt ut bak en proxy? Sjekk Brotli-støtten
En kopiert Accept-Encoding:br kan overgå dekoderstøtten i det hostede Requests-miljøet.
Sammenlign den bærbare maskinen og den hostede prosessen på to ulike lag:
| Lag | Spørsmål |
|---|---|
| Content-Encoding | Kan klienten dekomprimere de returnerte gzip/deflate/Brotli-bytene? |
| Charset | Hvordan blir dekomprimerte byte til tekst? |
Requests håndterer vanligvis gzip/deflate; Brotli krever et støttet installert bibliotek. En manuelt kopiert Accept-Encoding kan annonsere br når dette miljøet ikke kan dekode det. Valg av UTF-8-tekst dekomprimerer ikke Brotli.
Når forhandlingen bevisst begrenses:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Bruk den eksisterende Session, HTTPS-URL-en og de påkrevde headerne/autentiseringen. Sammenlign utgående Accept-Encoding, innkommende Content-Encoding og pakkestøtte på begge maskinene; en transformerende mellommann kan også levere utdatert metadata. En separat sammenligning av en offentlig side kan bruke Liste over HTTP-proxyer til proxy-URL-en der offentlige mellomledd er tillatt, uten arvede proxy-legitimasjoner, kopierte kontoheadere eller private kroppsdata.
Ellers bør du foretrekke normal klientforhandling. Requests sine praktiske content/text-grensesnitt dekoder støttet koding, så ikke dekomprimer utdataene deres igjen bare fordi headeren nevner det.