Odgovor Requests izgleda iskvaren iza proxyja? Provjerite podršku za Brotli
Kopirani Accept-Encoding:br može nadmašiti podršku dekodera u hostanom Requests okruženju.
Uporedite prenosnik i hostani proces na dva različita sloja:
| Sloj | Pitanje |
|---|---|
| Content-Encoding | Može li klijent dekompresovati vraćene gzip/deflate/Brotli bajtove? |
| Charset | Kako dekompresovani bajtovi postaju tekst? |
Requests obično obrađuje gzip/deflate; Brotli zahteva podržanu instaliranu biblioteku. Ručno kopiran Accept-Encoding može oglašavati br i kada ovo okruženje to ne može dekodirati. Izbor UTF-8 teksta ne dekompresuje Brotli.
Kada namerno ograničavate pregovaranje:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Koristite postojeći Session, HTTPS URL i potrebna zaglavlja/autentifikaciju. Uporedite odlazni Accept-Encoding, dolazni Content-Encoding i podršku paketa na oba računara; posrednik koji transformiše takođe može dati zastarele metapodatke. Odvojeno poređenje javne stranice može koristiti Lista HTTP proxyja za svoj proxy URL gde su javni posrednici dozvoljeni, bez nasleđenih proxy akreditiva, kopiranih zaglavlja naloga ili privatnih podataka tela.
Inače dajte prednost normalnom klijentskom pregovaranju. Praktična content/text interfejsa u Requests dekodiraju podržano kodiranje, pa ne dekompresujte njihov izlaz ponovo samo zato što ga zaglavlje imenuje.