Requests Response Looks Garbled Behind a Proxy? Check Brotli Support
A copied Accept-Encoding:br can outpace the hosted Requests environment's decoder support.
Compare the laptop and hosted process at two different layers:
| Layer | Question |
|---|---|
| Content-Encoding | Can the client decompress the returned gzip/deflate/Brotli bytes? |
| Charset | How do decompressed bytes become text? |
Requests normally handles gzip/deflate; Brotli requires a supported installed library. A manually copied Accept-Encoding may advertise br when this environment cannot decode it. UTF-8 text selection does not decompress Brotli.
When intentionally limiting negotiation:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Use the existing Session, HTTPS URL and required headers/authentication. Compare outgoing Accept-Encoding, incoming Content-Encoding and package support on both machines; a transforming intermediary can also supply stale metadata. A separate public-page comparison may use the HTTP proxy list for its proxy URL where public intermediaries are permitted, with no inherited proxy credentials, copied account headers or private body data.
Prefer normal client negotiation otherwise. Requests' convenient content/text interfaces decode supported coding, so do not decompress their output again just because the header names it.