Препредаване на 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 е съществуващият изход на отговора. Неговият статус и заглавия вече трябва да следват избраната политика; този фрагмент не реализира пълен прокси сървър.
Рамкирането на трансфера е отделно от content кодирането gzip. HTTP библиотеката на горния поток вече е обработила рамкирането, включително премахването на части, затова не копирайте Transfer-Encoding сляпо. Долният сървър рамкира собствения си отговор дори когато товарът остава gzip-кодиран.
response.text, последван от UTF-8 кодиране, също променя представянето и не може да запази произволни двоични данни. Затваряйте или изчерпвайте отговора на горния поток по всеки път и обработвайте HTTP грешките според прокси договора: този пример ги повдига вместо да ги препраща.