La risposta di Requests sembra corrotta dietro un proxy? Verifica il supporto a Brotli
Un Accept-Encoding:br copiato può superare il supporto del decodificatore dell ambiente Requests ospitato.
Confronta il portatile e il processo ospitato su due livelli diversi:
| Livello | Domanda |
|---|---|
| Content-Encoding | Il client può decomprimere i byte gzip/deflate/Brotli restituiti? |
| Charset | Come diventano testo i byte decompressi? |
Requests di solito gestisce gzip/deflate; Brotli richiede una libreria supportata e installata. Un Accept-Encoding copiato a mano può annunciare br quando questo ambiente non riesce a decodificarlo. Scegliere testo UTF-8 non decomprime Brotli.
Quando la negoziazione viene limitata di proposito:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Usa la Session esistente, l URL HTTPS e le intestazioni/autenticazione richieste. Confronta l Accept-Encoding in uscita, il Content-Encoding in ingresso e il supporto ai pacchetti su entrambe le macchine; un intermediario che trasforma può anche fornire metadati obsoleti. Un confronto separato su pagina pubblica può usare Elenco dei proxy HTTP per il proprio URL proxy dove gli intermediari pubblici sono consentiti, senza credenziali proxy ereditate, intestazioni di account copiate o dati privati del corpo.
Altrimenti preferisci la normale negoziazione del client. Le comode interfacce content/text di Requests decodificano la codifica supportata, quindi non decomprimere di nuovo il loro output solo perché l intestazione la nomina.