Observer la requête transférée d’un proxy à sa destination
Choisissez le bon point d’observation pour les en-têtes ajoutés ou modifiés après que le client a envoyé une requête HTTP.
Un client prépare une requête HTTP, et un proxy direct peut modifier ce message avant de le transmettre. La destination est l’endroit où la version transférée devient observable.
| Point d’observation | Message disponible à cet endroit |
|---|---|
| Objet de requête du client | La requête préparée pour le premier saut |
| Journal des requêtes de l’origine ou gestionnaire d’écho | La requête reçue après le transfert |
| Collection d’en-têtes de réponse du client | La réponse reçue sur le chemin de retour |
Pour un contrôle maîtrisé, utilisez un point de terminaison que vous exploitez et qui enregistre ou renvoie les en-têtes de requête reçus. Donnez à la requête un marqueur identifiable afin que l’enregistrement de l’origine puisse être associé à l’opération précise du client.
Dans une application basée sur WebClient, ResponseHeaders décrit la réponse renvoyée. Ce n’est pas un enregistrement de la requête du proxy vers la destination. Un serveur peut choisir de renvoyer les informations de la requête dans le corps de sa réponse, mais c’est un comportement applicatif.
Si le chemin comporte plusieurs intermédiaires, la destination voit leurs effets de transfert combinés. La seule présence d’un en-tête n’attribue pas une modification à un saut précis. Pour les champs d’API personnalisés, les règles de transfert et du champ Connection expliquent quand une altération est attendue.
Un tunnel HTTPS CONNECT ordinaire ajoute une autre frontière : la requête HTTP interne est chiffrée entre le client et le site web. Un proxy relais ne peut pas modifier ces en-têtes chiffrés. Les en-têtes de l’échange CONNECT appartiennent à cet échange distinct, tandis qu’un proxy d’inspection TLS géré a un rôle différent.