Respondo de Requests aspektas difektita malantaŭ prokura servilo? Kontrolu subtenon de Brotli
Kopiita Accept-Encoding:br povas antaŭi la subtenon de la malkodilo en la gastigita Requests-medio.
Komparu la tekkomputilon kaj la gastigitan procezon je du malsamaj tavoloj:
| Tavolo | Demando |
|---|---|
| Content-Encoding | Ĉu la kliento povas malpakigi la redonitajn bajtojn gzip/deflate/Brotli? |
| Charset | Kiel malpakitaj bajtoj fariĝas teksto? |
Requests kutime pritraktas gzip/deflate; Brotli postulas subtenatan instalitan bibliotekon. Mane kopiita Accept-Encoding povas anonci br dum ĉi tiu medio ne povas malkodi ĝin. Elekto de UTF-8-teksto ne malpakigas Brotli.
Kiam vi intence limigas la intertraktadon:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Uzu la ekzistantan Session, la HTTPS-adreson kaj la postulatajn kapliniojn/aŭtentikigon. Komparu la elirantan Accept-Encoding, la enirantan Content-Encoding kaj la pakaĵan subtenon sur ambaŭ maŝinoj; transformanta peranto ankaŭ povas liveri eksdatajn metadatumojn. Aparta komparo de publika paĝo povas uzi Listo de HTTP-prokuroj por sia prokura adreso kie publikaj perantoj estas permesitaj, sen hereditaj prokuraj akreditaĵoj, kopiitaj kontaj kaplinioj aŭ privataj korpaj datumoj.
Alikaze preferu normalan klientan intertraktadon. La oportunaj content/text-interfacoj de Requests malkodas subtenatan kodadon, do ne malpakigu ilian eligon denove nur ĉar la kaplinio nomas ĝin.