¿La respuesta de Requests se ve distorsionada tras un proxy? Comprueba la compatibilidad con Brotli
Un Accept-Encoding:br copiado puede superar la compatibilidad del decodificador del entorno Requests alojado.
Compare el portátil y el proceso alojado en dos capas distintas:
| Capa | Pregunta |
|---|---|
| Content-Encoding | ¿Puede el cliente descomprimir los bytes gzip/deflate/Brotli devueltos? |
| Charset | ¿Cómo se convierten los bytes descomprimidos en texto? |
Requests suele gestionar gzip/deflate; Brotli requiere una biblioteca compatible instalada. Un Accept-Encoding copiado a mano puede anunciar br cuando este entorno no puede decodificarlo. Elegir texto UTF-8 no descomprime Brotli.
Cuando se limita la negociación a propósito:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Use la Session existente, la URL HTTPS y las cabeceras/autenticación necesarias. Compare el Accept-Encoding saliente, el Content-Encoding entrante y la compatibilidad de paquetes en ambas máquinas; un intermediario que transforma también puede aportar metadatos obsoletos. Una comparación aparte de página pública puede usar Lista de proxies HTTP para su URL de proxy donde se permitan intermediarios públicos, sin credenciales de proxy heredadas, cabeceras de cuenta copiadas ni datos privados del cuerpo.
En caso contrario, prefiera la negociación normal del cliente. Las cómodas interfaces content/text de Requests decodifican la codificación admitida, así que no vuelva a descomprimir su salida solo porque la cabecera la nombre.