Requests-Antwort sieht hinter einem Proxy verzerrt aus? Brotli-Unterstützung prüfen
Ein kopiertes Accept-Encoding:br kann die Decoder-Unterstützung der gehosteten Requests-Umgebung überholen.
Vergleichen Sie den Laptop und den gehosteten Prozess auf zwei verschiedenen Ebenen:
| Ebene | Frage |
|---|---|
| Content-Encoding | Kann der Client die zurückgegebenen gzip/deflate/Brotli-Bytes dekomprimieren? |
| Charset | Wie werden dekomprimierte Bytes zu Text? |
Requests verarbeitet normalerweise gzip/deflate; Brotli erfordert eine unterstützte installierte Bibliothek. Ein manuell kopiertes Accept-Encoding kann br anbieten, wenn diese Umgebung es nicht dekodieren kann. Die Wahl von UTF-8-Text dekomprimiert Brotli nicht.
Wenn die Aushandlung bewusst eingeschränkt wird:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Verwenden Sie die vorhandene Session, die HTTPS-URL und die erforderlichen Header/Authentifizierung. Vergleichen Sie ausgehendes Accept-Encoding, eingehendes Content-Encoding und die Paketunterstützung auf beiden Rechnern; ein transformierender Vermittler kann auch veraltete Metadaten liefern. Ein separater Vergleich einer öffentlichen Seite kann HTTP-Proxy-Liste für ihre Proxy-URL verwenden, wo öffentliche Vermittler erlaubt sind, ohne geerbte Proxy-Anmeldedaten, kopierte Konto-Header oder private Body-Daten.
Bevorzugen Sie ansonsten die normale Client-Aushandlung. Die bequemen content/text-Schnittstellen von Requests dekodieren unterstützte Kodierung, dekomprimieren Sie deren Ausgabe also nicht erneut, nur weil der Header sie benennt.