Observe la solicitud reenviada de un proxy en su destino
Elija el punto de observación correcto para las cabeceras que se añaden o cambian después de que el cliente envíe una solicitud HTTP.
Un cliente prepara una solicitud HTTP, y un proxy directo puede cambiar ese mensaje antes de enviarlo. El destino es donde la versión reenviada se vuelve observable.
| Punto de observación | Mensaje disponible allí |
|---|---|
| Objeto de solicitud del cliente | La solicitud preparada para el primer salto |
| Registro de solicitudes del origen o controlador de eco | La solicitud recibida tras el reenvío |
| Colección de cabeceras de respuesta del cliente | La respuesta recibida en el camino de vuelta |
Para una comprobación controlada, use un extremo que usted opere y que registre o devuelva las cabeceras de solicitud recibidas. Dé a la solicitud una marca identificable para que el registro del origen pueda asociarse con la operación concreta del cliente.
En una aplicación basada en WebClient, ResponseHeaders describe la respuesta devuelta. No es un registro de la solicitud del proxy al destino. Un servidor puede optar por repetir información de la solicitud en el cuerpo de su respuesta, pero eso es comportamiento de la aplicación.
Si la ruta contiene varios intermediarios, el destino ve sus efectos de reenvío combinados. La mera presencia de una cabecera no atribuye un cambio a un salto concreto. Para los campos de API personalizados, las reglas de reenvío y del campo Connection explican cuándo se espera una alteración.
Un túnel HTTPS CONNECT normal añade otra frontera: la solicitud HTTP interna va cifrada entre el cliente y el sitio web. Un proxy de retransmisión no puede editar esas cabeceras cifradas. Las cabeceras del intercambio CONNECT pertenecen a ese intercambio separado, mientras que un proxy de inspección TLS gestionado tiene un papel distinto.