gzip-Bytes mat den Headere weiderleeden, déi se beschreiwen
Wielt kodéiert oder dekodéiert Payloaden an engem Proxy op Requests-Basis, a gitt duerno der Downstream-Antwert passend content-Headeren an hir eege Framing.
Wann Requests e Body schonn dekompriméiert huet, freet d'Weiderleede mat Content-Encoding: gzip de nächste Client, en nach eng Kéier ze dekompriméieren. Entscheet, wéi eng Payload-Duerstellung de Proxy schéckt, ier Dir seng Headere kopéiert.
| Geschecht Payload | Content-Headeren |
|---|---|
| Original kodéiert Bytes | Behale déi uwennbar Kodéierung an déi genee Payload-Längt |
| Dekodéiert Bytes | Entfernt déi dekodéiert Kodéierung; entfernt oder rechent déi entspriechend Längt nei |
Fir kodéiert Payload-Bytes liest dësen Deel de rouen Stream vun urllib3 ouni content-Dekodéierung:
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 ass déi existéierend Äntwertausgab. Hire Status an hir Headere musse schonn der gewielter Politik follegen; dësen Deel implementéiert keen komplette Proxy-Server.
D'Transport-Framing ass getrennt vun der gzip content-Kodéierung. D'Upstream-HTTP-Bibliothéik huet d'Framing schonn behandelt, och d'Entferne vu Stécker, also kopéiert Transfer-Encoding net blann. Den Downstream-Server framt seng eege Äntwert och wann de Payload gzip-kodéiert bleift.
response.text gefollegt vun UTF-8-Kodéierung ännert och d'Duerstellung an kann net arbiträär binär Daten erhalen. Maacht d'Upstream-Äntwert op all Wee zou oder verbraucht se, a behandelt HTTP-Feeler no dem Proxy-Kontrakt: dëst Beispill werft se amplaz se weiderzeleeden.