Observe a solicitude reenviada dun proxy no seu destino
Escolla o punto de observación correcto para as cabeceiras que se engaden ou cambian despois de que o cliente envíe unha solicitude HTTP.
Un cliente prepara unha solicitude HTTP, e un proxy directo pode cambiar esa mensaxe antes de enviala. O destino é onde a versión reenviada se volve observable.
| Punto de observación | Mensaxe dispoñible alí |
|---|---|
| Obxecto de solicitude do cliente | A solicitude preparada para o primeiro salto |
| Rexistro de solicitudes da orixe ou xestor de eco | A solicitude recibida despois do reenvío |
| Colección de cabeceiras de resposta do cliente | A resposta recibida no camiño de volta |
Para unha comprobación controlada, use un punto final que vostede xestione e que rexistre ou devolva as cabeceiras de solicitude recibidas. Dea á solicitude unha marca identificable para que o rexistro da orixe se poida asociar á operación concreta do cliente.
Nunha aplicación baseada en WebClient, ResponseHeaders describe a resposta devolta. Non é un rexistro da solicitude do proxy ao destino. Un servidor pode optar por repetir información da solicitude no corpo da súa resposta, pero iso é comportamento da aplicación.
Se o camiño contén varios intermediarios, o destino ve os seus efectos de reenvío combinados. A mera presenza dunha cabeceira non atribúe un cambio a un salto concreto. Para os campos de API personalizados, as regras de reenvío e do campo Connection explican cando se espera unha alteración.
Un túnel HTTPS CONNECT común engade outra fronteira: a solicitude HTTP interna vai cifrada entre o cliente e o sitio web. Un proxy de retransmisión non pode editar esas cabeceiras cifradas. As cabeceiras do intercambio CONNECT pertencen a ese intercambio separado, mentres que un proxy de inspección TLS xestionado ten un papel diferente.