Peleka baiti za gzip pamoja na vichwa vinavyozieleza
Chagua payload iliyosimbwa au iliyofunguliwa katika proksi inayotegemea Requests, kisha ipe jibu la chini vichwa vya content vinavyolingana na ufumbuzi wake.
Ikiwa Requests tayari imefungua mwili, kuupeleka kwa Content-Encoding: gzip kunaomba mteja anayefuata kuufungua tena. Amua ni uwakilishi upi wa payload ambao proksi inatuma kabla ya kunakili vichwa vyake.
| Payload iliyotumwa | Vichwa vya content |
|---|---|
| Baiti asili zilizosimbwa | Hifadhi usimbaji unaotumika na urefu kamili wa payload |
| Baiti zilizofunguliwa | Ondoa usimbaji uliofunguliwa; ondoa au hesabu upya urefu unaolingana |
Kwa baiti za payload zilizosimbwa, kipande hiki kinasoma mtiririko mbichi wa urllib3 bila usimbaji wa content:
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 ni matokeo ya jibu yaliyopo. Hali na vichwa vyake lazima tayari vifuate sera iliyochaguliwa; kipande hiki hakitekelezi seva kamili ya proksi.
Ufumbuzi wa uhamishaji ni tofauti na usimbaji wa content gzip. Maktaba ya HTTP ya juu tayari imeshughulikia ufumbuzi, ikiwa ni pamoja na kuondoa vipande, kwa hiyo usinakili Transfer-Encoding kwa upofu. Seva ya chini hufumbua jibu lake yenyewe hata wakati payload inabaki imesimbwa kwa gzip.
response.text ikifuatiwa na usimbaji wa UTF-8 pia hubadilisha uwakilishi na haiwezi kuhifadhi data ya binary isiyo ya kawaida. Funga au tumia jibu la juu kwenye kila njia, na shughulikia makosa ya HTTP kulingana na mkataba wa proksi: mfano huu unayatupa badala ya kuyapeleka.