Vidarebefordra gzip-byte med huvudena som beskriver dem
Välj kodad eller avkodad nyttolast i en Requests-baserad proxy och ge sedan nedströms svaret matchande content-huvuden och sin egen inramning.
Om Requests redan har dekomprimerat en body ber vidarebefordran med Content-Encoding: gzip nästa klient att dekomprimera den igen. Bestäm vilken nyttolastrepresentation proxyn skickar innan huvudena kopieras.
| Skickad nyttolast | Content-huvuden |
|---|---|
| Ursprungliga kodade byte | Behåll tillämplig kodning och exakt nyttolastlängd |
| Avkodade byte | Ta bort den avkodade kodningen; ta bort eller beräkna om motsvarande längd |
För kodade nyttolastbyte läser detta utdrag urllib3:s råström utan content-avkodning:
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 är den befintliga svarsutdata. Dess status och huvuden måste redan följa den valda policyn; detta utdrag implementerar inte en komplett proxyserver.
Transportinramning är åtskild från gzip content-kodning. HTTP-biblioteket uppströms har redan hanterat inramningen, inklusive borttagning av bitar, så kopiera inte Transfer-Encoding blint. Nedströms servern ramar in sitt eget svar även när nyttolasten förblir gzip-kodad.
response.text följt av UTF-8-kodning ändrar också representationen och kan inte bevara godtyckliga binära data. Stäng eller förbruka uppströms svaret på varje väg och hantera HTTP-fel enligt proxykontraktet: detta exempel kastar dem i stället för att vidarebefordra dem.