Препратете gzip бајти со заглавијата што ги опишуваат
Изберете кодиран или декодиран товар во прокси засновано на Requests, потоа дајте му на долниот одговор соодветни content заглавија и сопствено рамкирање.
Ако Requests веќе го декомпресирал телото, неговото препраќање со Content-Encoding: gzip бара следниот клиент повторно да го декомпресира. Одлучете кое претставување на товарот го испраќа проксито пред да ги копирате заглавијата.
| Испратен товар | Content заглавија |
|---|---|
| Оригинални кодирани бајти | Задржете го применливото кодирање и точната должина на товарот |
| Декодирани бајти | Отстранете го декодираното кодирање; отстранете или пресметајте ја повторно соодветната должина |
За кодирани бајти на товарот, овој фрагмент го чита суровиот тек на urllib3 без 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 е постоечкиот излез на одговорот. Неговиот статус и заглавија веќе мора да ја следат избраната политика; овој фрагмент не имплементира целосен прокси сервер.
Рамкирањето на преносот е одделно од gzip content кодирањето. HTTP библиотеката на горниот тек веќе го обработила рамкирањето, вклучително отстранувањето на делови, затоа не копирајте Transfer-Encoding слепо. Долниот сервер го рамкира сопствениот одговор дури и кога товарот останува gzip-кодиран.
response.text проследено со UTF-8 кодирање исто така го менува претставувањето и не може да зачува произволни бинарни податоци. Затворете или искористете го одговорот на горниот тек на секоја патека и ракувајте со HTTP грешките според прокси договорот: овој пример ги фрла наместо да ги препраќа.