Plusendi gzip-bajtojn kun la kaplinioj, kiuj priskribas ilin
Elektu koditajn aŭ malkoditajn ŝarĝojn en Requests-bazita prokuro, poste donu al la malsupra respondo konformajn content-kapliniojn kaj sian propran kadrigon.
Se Requests jam malkunpremis korpon, plusendi ĝin kun Content-Encoding: gzip petas la sekvan klienton malkunpremi ĝin denove. Decidu, kiun ŝarĝprezenton la prokuro sendas, antaŭ ol kopii ĝiajn kapliniojn.
| Sendita ŝarĝo | Content-kaplinioj |
|---|---|
| Originalaj koditaj bajtoj | Konservu la aplikeblan kodadon kaj la precizan ŝarĝlongon |
| Malkoditaj bajtoj | Forigu la malkoditan kodadon; forigu aŭ rekalkulu la respondan longon |
Por koditaj ŝarĝbajtoj, ĉi tiu fragmento legas la krudan fluon de urllib3 sen content-malkodado:
with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
upstream.raise_for_status()
for block in upstream.raw.stream(65536, decode_content=False):
downstream.write(block)downstream estas la ekzistanta responda eligo. Ĝia stato kaj kaplinioj jam devas sekvi la elektitan politikon; ĉi tiu fragmento ne implementas kompletan prokuran servilon.
Transiga kadrigo estas aparta de gzip content-kodado. La supra HTTP-biblioteko jam traktis la kadrigon, inkluzive forigon de blokoj, do ne kopiu Transfer-Encoding blinde. La malsupra servilo kadrigas sian propran respondon eĉ kiam la ŝarĝo restas gzip-kodita.
response.text sekvata de UTF-8-kodado ankaŭ ŝanĝas la prezenton kaj ne povas konservi arbitrajn binaraĵojn. Fermu aŭ konsumu la supran respondon sur ĉiu vojo, kaj traktu HTTP-erarojn laŭ la prokura kontrakto: ĉi tiu ekzemplo ĵetas ilin anstataŭ plusendi ilin.