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.
Usporedite prijenosnik i hostani proces na dva različita sloja:
| Sloj | Pitanje |
|---|---|
| Content-Encoding | Može li klijent dekomprimirati vraćene gzip/deflate/Brotli bajtove? |
| Charset | Kako dekomprimirani bajtovi postaju tekst? |
Requests obično obrađuje gzip/deflate; Brotli zahtijeva podržanu instaliranu biblioteku. Ručno kopiran Accept-Encoding može oglašavati br i kada ovo okruženje to ne može dekodirati. Odabir UTF-8 teksta ne dekomprimira Brotli.
Kada namjerno ograničavate pregovaranje:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Upotrijebite postojeći Session, HTTPS URL i potrebna zaglavlja/autentifikaciju. Usporedite odlazni Accept-Encoding, dolazni Content-Encoding i podršku paketa na oba računala; posrednik koji pretvara također može dati zastarjele metapodatke. Odvojena usporedba javne stranice može koristiti Popis HTTP proxyja za svoj proxy URL gdje su javni posrednici dopušteni, bez naslijeđenih proxy vjerodajnica, kopiranih zaglavlja računa ili privatnih podataka tijela.
Inače dajte prednost normalnom klijentskom pregovaranju. Praktična content/text sučelja u Requests dekodiraju podržano kodiranje, pa ne dekomprimirajte njihov izlaz ponovno samo zato što ga zaglavlje imenuje.