Observe o pedido reencaminhado de um proxy no seu destino
Escolha o ponto de observação correto para cabeçalhos adicionados ou alterados depois que o cliente envia um pedido HTTP.
Um cliente prepara um pedido HTTP, e um proxy de encaminhamento pode alterar essa mensagem antes de a enviar adiante. O destino é onde a versão reencaminhada se torna observável.
| Ponto de observação | Mensagem disponível aí |
|---|---|
| Objeto de pedido do cliente | O pedido preparado para o primeiro salto |
| Registo de pedidos da origem ou processador de eco | O pedido recebido após o reencaminhamento |
| Coleção de cabeçalhos de resposta do cliente | A resposta recebida no caminho de volta |
Para uma verificação controlada, use um ponto final que você próprio opera e que registe ou devolva os cabeçalhos do pedido recebido. Dê ao pedido um marcador identificável para que o registo da origem possa ser associado à operação concreta do cliente.
Numa aplicação baseada em WebClient, ResponseHeaders descreve a resposta devolvida. Não é um registo do pedido do proxy ao destino. Um servidor pode optar por repetir informação do pedido no corpo da resposta, mas isso é comportamento da aplicação.
Se o caminho contiver vários intermediários, o destino vê os seus efeitos de encaminhamento combinados. A mera presença de um cabeçalho não atribui uma alteração a um salto concreto. Para campos de API personalizados, as regras de encaminhamento e do campo Connection explicam quando se espera uma alteração.
Um túnel HTTPS CONNECT comum acrescenta outra fronteira: o pedido HTTP interno é cifrado entre o cliente e o site. Um proxy de retransmissão não pode editar esses cabeçalhos cifrados. Os cabeçalhos do intercâmbio CONNECT pertencem a esse intercâmbio separado, enquanto um proxy de inspeção TLS gerido tem um papel diferente.