Requests-svar ser forvrænget ud bag en proxy? Tjek Brotli-understøttelse
En kopieret Accept-Encoding:br kan overhale det hostede Requests-miljøs dekoderunderstøttelse.
Sammenlign bærbaren og den hostede proces på to forskellige lag:
| Lag | Spørgsmål |
|---|---|
| Content-Encoding | Kan klienten dekomprimere de returnerede gzip/deflate/Brotli-byte? |
| Charset | Hvordan bliver dekomprimerede byte til tekst? |
Requests håndterer normalt gzip/deflate; Brotli kræver et understøttet installeret bibliotek. Et manuelt kopieret Accept-Encoding kan annoncere br, når dette miljø ikke kan afkode det. Valg af UTF-8-tekst dekomprimerer ikke Brotli.
Når forhandlingen bevidst begrænses:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Brug den eksisterende Session, HTTPS-URL og de krævede headere/autentificering. Sammenlign udgående Accept-Encoding, indgående Content-Encoding og pakkeunderstøttelse på begge maskiner; en transformerende mellemled kan også levere forældede metadata. En separat sammenligning af en offentlig side kan bruge Liste over HTTP-proxyer til dens proxy-URL, hvor offentlige mellemled er tilladt, uden nedarvede proxy-legitimationsoplysninger, kopierede kontiheadere eller private kropsdata.
Foretræk ellers normal klientforhandling. Requests behagelige content/text-grænseflader afkoder understøttet kodning, så dekomprimer ikke deres output igen, blot fordi headeren nævner det.