Odgovor Requests je za proxy videti popačen? Preverite podporo Brotli
Kopiran Accept-Encoding:br lahko prehiti podporo dekoderja v gostujočem okolju Requests.
Primerjajte prenosnik in gostujoči proces na dveh različnih plasteh:
| Plast | Vprašanje |
|---|---|
| Content-Encoding | Ali lahko odjemalec dekomprimira vrnjene bajte gzip/deflate/Brotli? |
| Charset | Kako dekomprimirani bajti postanejo besedilo? |
Requests običajno obdela gzip/deflate; Brotli zahteva nameščeno podprto knjižnico. Ročno kopiran Accept-Encoding lahko oglašuje br, ko tega okolje ne more dekodirati. Izbira besedila UTF-8 ne dekomprimira Brotli.
Ko je pogajanje namerno omejeno:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Uporabite obstoječi Session, naslov HTTPS in zahtevane glave/avtentikacijo. Primerjajte odhodni Accept-Encoding, vhodni Content-Encoding in podporo paketov na obeh strojih; posrednik, ki preoblikuje, lahko priskrbi tudi zastarele metapodatke. Ločena primerjava javne strani lahko uporabi Seznam proxyjev HTTP za svoj naslov proxy, kjer so javni posredniki dovoljeni, brez podedovanih proxy poverilnic, kopiranih glav računa ali zasebnih podatkov telesa.
Sicer dajte prednost običajnemu pogajanju odjemalca. Priročni vmesniki content/text v Requests dekodirajo podprto kodiranje, zato njihovega izhoda ne dekomprimirajte znova samo zato, ker ga glava imenuje.