Odpowiedź Requests wygląda na zniekształconą za proxy? Sprawdź obsługę Brotli
Skopiowany Accept-Encoding:br może wyprzedzić obsługę dekodera w hostowanym środowisku Requests.
Porównaj laptop i hostowany proces na dwóch różnych warstwach:
| Warstwa | Pytanie |
|---|---|
| Content-Encoding | Czy klient potrafi zdekompresować zwrócone bajty gzip/deflate/Brotli? |
| Charset | Jak zdekompresowane bajty stają się tekstem? |
Requests zwykle obsługuje gzip/deflate; Brotli wymaga zainstalowanej obsługiwanej biblioteki. Ręcznie skopiowany Accept-Encoding może rozgłaszać br, gdy to środowisko nie potrafi go zdekodować. Wybór tekstu UTF-8 nie dekompresuje Brotli.
Gdy negocjacja jest celowo ograniczana:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Użyj istniejącej Session, adresu HTTPS i wymaganych nagłówków/uwierzytelniania. Porównaj wychodzący Accept-Encoding, przychodzący Content-Encoding i obsługę pakietów na obu maszynach; pośrednik przekształcający może też dostarczać nieaktualne metadane. Osobne porównanie strony publicznej może użyć Lista proxy HTTP jako adresu proxy tam, gdzie dozwolone są publiczne pośredniki, bez odziedziczonych danych uwierzytelniających proxy, skopiowanych nagłówków konta ani prywatnych danych treści.
W przeciwnym razie preferuj normalną negocjację klienta. Wygodne interfejsy content/text w Requests dekodują obsługiwane kodowanie, więc nie dekompresuj ich wyniku ponownie tylko dlatego, że nagłówek go nazywa.