Stuur gzip-grepe deur met die opkoppe wat hulle beskryf
Kies geënkodeerde of gedekodeerde vragte in 'n Requests-gebaseerde proxy en gee dan die stroomafwaartse antwoord ooreenstemmende inhoudopkoppe en sy eie raamwerk.
As Requests reeds 'n liggaam gedecomprimeer het, word die volgende kliënt gevra om dit weer te decomprimeer wanneer dit met Content-Encoding: gzip deurgestuur word. Besluit watter vragvoorstelling die proxy stuur voordat sy opkoppe gekopieer word.
| Vrag gestuur | Inhoudopkoppe |
|---|---|
| Oorspronklike geënkodeerde grepe | Behou die toepaslike kodering en die presiese vraglengte |
| Gedekodeerde grepe | Verwyder die gedekodeerde kodering; verwyder of herbereken die ooreenstemmende lengte |
Vir geënkodeerde vrag-grepe lees hierdie fragment urllib3 se rou stroom sonder inhouddekodering:
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 die bestaande antwoord-uitset. Sy status en opkoppe moet reeds die gekose beleid volg; hierdie fragment implementeer nie 'n volledige proxy-bediener nie.
Oordragraamwerk is apart van gzip-inhoudkodering. Die opstroom-HTTP-biblioteek het reeds die raamwerk hanteer, insluitend die verwydering van stukke, so moenie Transfer-Encoding blindelings kopieer nie. Die stroomafwaartse bediener raam sy eie antwoord selfs wanneer die vrag gzip-geënkodeer bly.
response.text gevolg deur UTF-8-kodering verander ook die voorstelling en kan nie arbitrêre binêre data bewaar nie. Sluit of verbruik die opstroom-antwoord op elke pad, en hanteer HTTP-foute volgens die proxy-kontrak: hierdie voorbeeld gooi hulle eerder as om dit deur te stuur.