La réponse de Requests semble corrompue derrière un proxy ? Vérifiez la prise en charge de Brotli
Un Accept-Encoding:br copié peut dépasser la prise en charge du décodeur de l environnement Requests hébergé.
Comparez l ordinateur portable et le processus hébergé sur deux couches différentes :
| Couche | Question |
|---|---|
| Content-Encoding | Le client peut-il décompresser les octets gzip/deflate/Brotli renvoyés ? |
| Charset | Comment les octets décompressés deviennent-ils du texte ? |
Requests gère normalement gzip/deflate ; Brotli nécessite une bibliothèque prise en charge installée. Un Accept-Encoding copié à la main peut annoncer br alors que cet environnement ne sait pas le décoder. Choisir du texte UTF-8 ne décompresse pas Brotli.
Lorsque la négociation est volontairement limitée :
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Utilisez la Session existante, l URL HTTPS et les en-têtes/authentification requis. Comparez l Accept-Encoding sortant, le Content-Encoding entrant et la prise en charge des paquets sur les deux machines ; un intermédiaire transformant peut aussi fournir des métadonnées périmées. Une comparaison séparée de page publique peut utiliser Liste de proxys HTTP pour son URL de proxy là où les intermédiaires publics sont autorisés, sans identifiants de proxy hérités, en-têtes de compte copiés ni données de corps privées.
Sinon, privilégiez la négociation normale du client. Les interfaces pratiques content/text de Requests décodent la compression prise en charge, donc ne décompressez pas leur sortie une seconde fois simplement parce que l en-tête la nomme.