Respons Requests tampak rusak di balik proxy? Periksa dukungan Brotli
Accept-Encoding:br yang disalin dapat melampaui dukungan dekoder lingkungan Requests terkelola.
Bandingkan laptop dan proses terkelola pada dua lapisan berbeda:
| Lapisan | Pertanyaan |
|---|---|
| Content-Encoding | Bisakah klien mendekompresi byte gzip/deflate/Brotli yang dikembalikan? |
| Charset | Bagaimana byte hasil dekompresi menjadi teks? |
Requests biasanya menangani gzip/deflate; Brotli memerlukan pustaka terpasang yang didukung. Accept-Encoding yang disalin manual dapat mengiklankan br padahal lingkungan ini tidak dapat mendekodenya. Pemilihan teks UTF-8 tidak mendekompresi Brotli.
Saat negosiasi sengaja dibatasi:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Gunakan Session yang ada, URL HTTPS, serta header/autentikasi yang diperlukan. Bandingkan Accept-Encoding keluar, Content-Encoding masuk, dan dukungan paket di kedua mesin; perantara yang mengubah juga dapat memasok metadata usang. Perbandingan halaman publik terpisah dapat memakai Daftar proxy HTTP untuk URL proxy-nya bila perantara publik diizinkan, tanpa kredensial proxy warisan, header akun hasil salinan, atau data isi privat.
Jika tidak, utamakan negosiasi klien normal. Antarmuka content/text Requests yang praktis mendekode pengodean yang didukung, jadi jangan mendekompresi keluarannya lagi hanya karena header menyebut namanya.