Одговорот на 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 прокси за нејзиниот прокси URL каде што јавните посредници се дозволени, без наследени прокси акредитиви, копирани заглавија на сметка или приватни податоци од телото.
Инаку претпочитајте нормално клиентско преговарање. Практичните content/text интерфејси на Requests го декодираат поддржаното кодирање, затоа не декомпресирајте го нивниот излез повторно само затоа што заглавието го именува.