Videresend gzip-bytes med de headere, der beskriver dem
Vælg kodet eller afkodet payload i en Requests-baseret proxy, og giv derefter det nedstrøms svar matchende content-headere og sin egen framing.
Hvis Requests allerede har dekomprimeret en body, beder videresendelse med Content-Encoding: gzip den næste klient om at dekomprimere den igen. Beslut, hvilken payload-repræsentation proxyen sender, før dens headere kopieres.
| Sendt payload | Content-headere |
|---|---|
| Oprindelige kodede bytes | Behold den relevante kodning og den præcise payload-længde |
| Afkodede bytes | Fjern den afkodede kodning; fjern eller genberegn den tilsvarende længde |
For kodede payload-bytes læser dette uddrag urllib3s rå stream uden content-afkodning:
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 det eksisterende svaroutput. Dets status og headere skal allerede følge den valgte politik; dette uddrag implementerer ikke en komplet proxyserver.
Transport-framing er adskilt fra gzip content-kodning. Den opstrøms HTTP-bibliotek har allerede håndteret framing, inklusive fjernelse af chunks, så kopiér ikke Transfer-Encoding i blinde. Den nedstrøms server framer sit eget svar, selv når payloaden forbliver gzip-kodet.
response.text efterfulgt af UTF-8-kodning ændrer også repræsentationen og kan ikke bevare vilkårlige binære data. Luk eller forbrug det opstrøms svar på hver vej, og håndtér HTTP-fejl i henhold til proxy-kontrakten: dette eksempel kaster dem i stedet for at videresende dem.