A resposta de Requests vese distorsionada detrás dun proxy? Comproba a compatibilidade con Brotli
Un Accept-Encoding:br copiado pode superar a compatibilidade do decodificador da contorna Requests aloxada.
Compare o portátil e o proceso aloxado en dúas capas distintas:
| Capa | Pregunta |
|---|---|
| Content-Encoding | Pode o cliente descomprimir os bytes gzip/deflate/Brotli devoltos? |
| Charset | Como se converten os bytes descomprimidos en texto? |
Requests adoita xestionar gzip/deflate; Brotli require unha biblioteca compatible instalada. Un Accept-Encoding copiado á man pode anunciar br cando esta contorna non pode decodificalo. Escoller texto UTF-8 non descomprime Brotli.
Cando se limita a 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 a Session existente, o URL HTTPS e as cabeceiras/autenticación necesarias. Compare o Accept-Encoding saínte, o Content-Encoding entrante e a compatibilidade de paquetes nas dúas máquinas; un intermediario que transforma tamén pode fornecer metadatos obsoletos. Unha comparación aparte de páxina pública pode usar Lista de proxies HTTP para o seu URL de proxy onde se permiten intermediarios públicos, sen credenciais de proxy herdadas, cabeceiras de conta copiadas nin datos privados do corpo.
En caso contrario, prefira a negociación normal do cliente. As cómodas interfaces content/text de Requests decodifican a codificación admitida, así que non volva descomprimir a súa saída só porque a cabeceira a nomea.