Videresend gzip-byter med headerne som beskriver dem
Velg kodet eller dekodet nyttelast i en Requests-basert proxy, og gi deretter nedstrømsresponsen samsvarende content-headere og sin egen innramming.
Hvis Requests allerede har dekomprimert en body, ber videresending med Content-Encoding: gzip neste klient om å dekomprimere den på nytt. Bestem hvilken nyttelastrepresentasjon proxyen sender før headerne kopieres.
| Sendt nyttelast | Content-headere |
|---|---|
| Opprinnelige kodede byter | Behold gjeldende koding og nøyaktig nyttelastlengde |
| Dekodede byter | Fjern den dekodede kodingen; fjern eller beregn den tilsvarende lengden på nytt |
For kodede nyttelastbyter leser dette utdraget urllib3s rå strøm uten content-dekoding:
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 er den eksisterende responsutdataen. Statusen og headerne må allerede følge den valgte policyen; dette utdraget implementerer ikke en fullstendig proxyserver.
Transportinnramming er atskilt fra gzip content-koding. HTTP-biblioteket oppstrøms har allerede håndtert innrammingen, inkludert fjerning av biter, så ikke kopier Transfer-Encoding blindt. Nedstrømsserveren rammer inn sitt eget svar selv når nyttelasten forblir gzip-kodet.
response.text etterfulgt av UTF-8-koding endrer også representasjonen og kan ikke bevare vilkårlige binære data. Lukk eller forbruk oppstrømsresponsen på hver vei, og håndter HTTP-feil i henhold til proxy-kontrakten: dette eksempelet kaster dem i stedet for å videresende dem.