Observeer het doorgestuurde verzoek van een proxy bij de bestemming
Kies het juiste observatiepunt voor headers die worden toegevoegd of gewijzigd nadat de client een HTTP-verzoek verstuurt.
Een client bereidt een HTTP-verzoek voor, en een forward-proxy kan dat bericht wijzigen voordat het verder wordt gestuurd. De bestemming is de plek waar de doorgestuurde versie waarneembaar wordt.
| Observatiepunt | Bericht dat daar beschikbaar is |
|---|---|
| Verzoekobject van de client | Het verzoek dat voor de eerste hop is voorbereid |
| Verzoeklog van de oorsprong of echo-handler | Het verzoek dat na het doorsturen is ontvangen |
| Verzameling antwoordheaders van de client | Het antwoord dat op de terugweg is ontvangen |
Gebruik voor een gecontroleerde controle een eindpunt dat u zelf beheert en dat de ontvangen verzoekheaders vastlegt of teruggeeft. Geef het verzoek een herkenbare markering zodat het oorsprongsrecord aan de specifieke clientbewerking kan worden gekoppeld.
In een op WebClient gebaseerde toepassing beschrijft ResponseHeaders het teruggegeven antwoord. Het is geen vastlegging van het verzoek van de proxy aan de bestemming. Een server kan ervoor kiezen verzoeksinformatie in de antwoordbody te herhalen, maar dat is toepassingsgedrag.
Bevat het pad meerdere tussenstations, dan ziet de bestemming hun gecombineerde doorstuureffecten. De aanwezigheid van een header alleen schrijft een wijziging niet toe aan één bepaalde hop. Voor aangepaste API-velden leggen de regels voor doorsturen en het Connection-veld uit wanneer een wijziging wordt verwacht.
Een gewone HTTPS CONNECT-tunnel voegt een andere grens toe: het binnenste HTTP-verzoek is versleuteld tussen de client en de website. Een relay-proxy kan die versleutelde headers niet bewerken. Headers in de CONNECT-uitwisseling horen bij die afzonderlijke uitwisseling, terwijl een beheerde TLS-inspectieproxy een andere rol heeft.