Transmettre les octets gzip avec les en-têtes qui les décrivent
Choisissez des charges utiles encodées ou décodées dans un proxy basé sur Requests, puis donnez à la réponse en aval les en-têtes de contenu correspondants et son propre cadrage.
Si Requests a déjà décompressé un corps, le transmettre avec Content-Encoding: gzip demande au client suivant de le décompresser à nouveau. Décidez quelle représentation de la charge utile le proxy envoie avant de copier ses en-têtes.
| Charge utile envoyée | En-têtes de contenu |
|---|---|
| Octets encodés d'origine | Conservez le codage applicable et la longueur exacte de la charge utile |
| Octets décodés | Supprimez le codage décodé ; supprimez ou recalculez la longueur correspondante |
Pour les octets de charge utile encodés, cet extrait lit le flux brut d'urllib3 sans décodage de contenu :
with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
upstream.raise_for_status()
for block in upstream.raw.stream(65536, decode_content=False):
downstream.write(block)downstream est la sortie de réponse existante. Son statut et ses en-têtes doivent déjà suivre la politique choisie ; cet extrait n'implémente pas un serveur proxy complet.
Le cadrage de transfert est distinct du codage de contenu gzip. La bibliothèque HTTP en amont a déjà géré le cadrage, y compris la suppression des fragments, donc ne copiez pas Transfer-Encoding aveuglément. Le serveur en aval cadre sa propre réponse même lorsque la charge utile reste encodée en gzip.
response.text suivi d'un encodage UTF-8 modifie aussi la représentation et ne peut pas préserver des données binaires arbitraires. Fermez ou consommez la réponse en amont sur chaque chemin, et gérez les erreurs HTTP selon le contrat du proxy : cet exemple les lève au lieu de les transmettre.