gzip-Bytes mit den Headern weiterleiten, die sie beschreiben
Wählen Sie in einem Requests-basierten Proxy kodierte oder dekodierte Payloads und geben Sie der nachgelagerten Antwort passende Content-Header und ihre eigene Framing-Struktur.
Wenn Requests einen Body bereits dekomprimiert hat, verlangt das Weiterleiten mit Content-Encoding: gzip vom nächsten Client, ihn erneut zu dekomprimieren. Legen Sie fest, welche Payload-Darstellung der Proxy sendet, bevor Sie die Header kopieren.
| Gesendete Payload | Content-Header |
|---|---|
| Ursprüngliche kodierte Bytes | Die anwendbare Kodierung und die genaue Payload-Länge beibehalten |
| Dekodierte Bytes | Die dekodierte Kodierung entfernen; die zugehörige Länge entfernen oder neu berechnen |
Für kodierte Payload-Bytes liest dieses Fragment den Rohstream von urllib3 ohne Content-Dekodierung:
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 ist die vorhandene Antwortausgabe. Status und Header müssen bereits der gewählten Richtlinie folgen; dieses Fragment implementiert keinen vollständigen Proxyserver.
Transfer-Framing ist von der gzip-Content-Kodierung getrennt. Die vorgelagerte HTTP-Bibliothek hat das Framing einschließlich der Chunk-Entfernung bereits erledigt, daher Transfer-Encoding nicht blind kopieren. Der nachgelagerte Server rahmt seine eigene Antwort, auch wenn die Payload gzip-kodiert bleibt.
response.text gefolgt von UTF-8-Kodierung ändert ebenfalls die Darstellung und kann beliebige Binärdaten nicht bewahren. Schließen oder verbrauchen Sie die vorgelagerte Antwort auf jedem Pfad und behandeln Sie HTTP-Fehler gemäß dem Proxy-Vertrag: Dieses Beispiel wirft sie, statt sie weiterzuleiten.