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 laptop 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 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 dekompresuje 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()Koristite postojeći Session, HTTPS URL i potrebne 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 zastarjele metapodatke. Odvojeno poređenje javne stranice može koristiti Lista HTTP proxyja za svoj proxy URL gdje su javni posrednici dopušteni, bez naslijeđenih proxy akreditiva, kopiranih zaglavlja računa ili privatnih podataka tijela.
Inače preferirajte normalno klijentsko pregovaranje. Praktični content/text interfejsi u Requests dekodiraju podržano kodiranje, pa ne dekompresujte njihov izlaz ponovo samo zato što ga zaglavlje imenuje.