Ipaabot ang mga byte ng gzip kasama ang mga header na naglalarawan sa kanila
Pumili ng naka-encode o na-decode na payload sa isang proxy na nakabatay sa Requests, pagkatapos ay bigyan ang downstream na tugon ng tugmang content header at sarili nitong framing.
Kung na-decompress na ng Requests ang isang body, ang pagpapadala nito nang may Content-Encoding: gzip ay humihiling sa susunod na kliyente na i-decompress itong muli. Magpasya kung aling representasyon ng payload ang ipinapadala ng proxy bago kopyahin ang mga header nito.
| Ipinadalang payload | Mga content header |
|---|---|
| Orihinal na naka-encode na byte | Panatilihin ang naaangkop na encoding at ang eksaktong haba ng payload |
| Na-decode na byte | Alisin ang na-decode na encoding; alisin o muling kalkulahin ang katumbas na haba |
Para sa naka-encode na payload byte, binabasa ng bahaging ito ang raw stream ng urllib3 nang walang content decoding:
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 ay ang umiiral na output ng tugon. Ang status at mga header nito ay dapat nang sumunod sa piniling patakaran; hindi nagpapatupad ang bahaging ito ng kumpletong proxy server.
Ang transfer framing ay hiwalay sa gzip content encoding. Naasikaso na ng upstream HTTP library ang framing, kabilang ang pag-alis ng chunk, kaya huwag bulag na kopyahin ang Transfer-Encoding. Ang downstream server ay nagfa-frame ng sarili nitong tugon kahit nananatiling naka-encode ng gzip ang payload.
response.text na sinusundan ng UTF-8 encoding ay nagbabago rin ng representasyon at hindi kayang pangalagaan ang arbitraryong binary data. Isara o gamitin ang upstream na tugon sa bawat landas, at pangasiwaan ang mga HTTP error ayon sa kontrata ng proxy: itinatapon ng halimbawang ito ang mga ito sa halip na ipaabot.