Перасылайце байты 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 згодна з кантрактам проксі: гэты прыклад уздымае іх замест перасылкі.