Requests-vastaus näyttää särkyneeltä välityspalvelimen takana? Tarkista Brotli-tuki
Kopioitu Accept-Encoding:br voi ohittaa isännöidyn Requests-ympäristön dekooderin tuen.
Vertaa kannettavaa ja isännöityä prosessia kahdella eri kerroksella:
| Kerros | Kysymys |
|---|---|
| Content-Encoding | Pystyykö asiakas purkamaan palautetut gzip/deflate/Brotli-tavut? |
| Charset | Miten puretut tavut muuttuvat tekstiksi? |
Requests käsittelee yleensä gzip/deflate-muodon; Brotli vaatii tuetun asennetun kirjaston. Käsin kopioitu Accept-Encoding voi ilmoittaa br, vaikka tämä ympäristö ei pysty purkamaan sitä. UTF-8-tekstin valinta ei pura Brotlia.
Kun neuvottelua rajoitetaan tarkoituksella:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Käytä olemassa olevaa Sessionia, HTTPS-osoitetta ja vaadittuja otsakkeita/todennusta. Vertaa lähtevää Accept-Encoding-arvoa, saapuvaa Content-Encoding-arvoa ja pakettitukea molemmilla koneilla; muuntava välittäjä voi myös tarjota vanhentunutta metatietoa. Erillinen julkisen sivun vertailu voi käyttää HTTP-välityspalvelinlista-listaa välityspalvelimen osoitteeseen siellä, missä julkiset välittäjät sallitaan, ilman perittyjä välityspalvelimen tunnuksia, kopioituja tilin otsakkeita tai yksityisiä runkotietoja.
Muuten suosi asiakkaan normaalia neuvottelua. Requestsin kätevät content/text-rajapinnat purkavat tuetun koodauksen, joten älä pura niiden tulosta uudelleen vain siksi, että otsake nimeää sen.