Одговор Requests изгледа искварен иза проксија? Проверите подршку за Brotli
Копирани Accept-Encoding:br може надмашити подршку декодера у хостованом Requests окружењу.
Упоредите преносни рачунар и хостовани процес на два различита слоја:
| Слој | Питање |
|---|---|
| Content-Encoding | Може ли клијент да декомпресује враћене gzip/deflate/Brotli бајтове? |
| Charset | Како декомпресовани бајтови постају текст? |
Requests обично обрађује gzip/deflate; Brotli захтева подржану инсталирану библиотеку. Ручно копиран Accept-Encoding може оглашавати br и када ово окружење не може да га декодира. Избор UTF-8 текста не декомпресује Brotli.
Када намерно ограничавате преговарање:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Користите постојећи Session, HTTPS URL и потребна заглавља/аутентификацију. Упоредите одлазни Accept-Encoding, долазни Content-Encoding и подршку пакета на оба рачунара; посредник који трансформише такође може дати застареле метаподатке. Одвојено поређење јавне странице може користити Листа HTTP проксија за свој proxy URL где су јавни посредници дозвољени, без наслеђених proxy акредитива, копираних заглавља налога или приватних података тела.
У осталом дајте предност нормалном клијентском преговарању. Практична content/text интерфејса у Requests декодирају подржано кодирање, па не декомпресујте њихов излаз поново само зато што га заглавље именује.