Stjoer gzip-bytes troch mei de headers dy't se beskriuwe
Kies kodearre of dekodearre payloads yn in proxy basearre op Requests, en jou dan it antwurd streamôf de byhearrende content-headers en syn eigen framing.
As Requests al in lichem dekomprimearre hat, freget trochstjoeren mei Content-Encoding: gzip de folgjende klient om it opnij te dekomprimearjen. Beslis hokker payloadwerjefte de proxy stjoert foardat de headers kopiearre wurde.
| Stjoerde payload | Content-headers |
|---|---|
| Oarspronklike kodearre bytes | Hâld de tapaslike kodearring en de krekte payloadlingte |
| Dekodearre bytes | Ferwiderje de dekodearre kodearring; ferwiderje of berekkenje de byhearrende lingte opnij |
Foar kodearre payloadbytes lêst dit fragmint de rauwe stream fan urllib3 sûnder content-dekodearring:
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 is de besteande antwurdútfier. Syn status en headers moatte al it keazen belied folgje; dit fragmint ymplementearret gjin folsleine proxyserver.
Oerdrachtsframing is los fan gzip content-kodearring. De upstream HTTP-biblioteek hat de framing al ôfhannele, ynklusyf it fuortheljen fan stikken, dus kopiearje Transfer-Encoding net blyn. De downstream-server framed syn eigen antwurd sels as de payload gzip-kodearre bliuwt.
response.text folge troch UTF-8-kodearring feroaret ek de werjefte en kin willekeurige binaire gegevens net bewarje. Slút of konsumearje it upstream-antwurd op elk paad, en behannelje HTTP-flaters neffens it proxy-kontrakt: dit foarbyld smyt se ynstee fan se troch te stjoeren.