Observer en proxys videresendte forespørsel ved destinasjonen
Velg riktig observasjonspunkt for headere som legges til eller endres etter at klienten har sendt en HTTP-forespørsel.
En klient forbereder en HTTP-forespørsel, og en videresendende proxy kan endre meldingen før den sendes videre. Destinasjonen er stedet der den videresendte versjonen blir observerbar.
| Observasjonspunkt | Melding tilgjengelig der |
|---|---|
| Klientens forespørselsobjekt | Forespørselen som er forberedt for det første hoppet |
| Opphavets forespørselslogg eller ekko-behandler | Forespørselen som mottas etter videresendingen |
| Klientens samling av svarheadere | Svaret som mottas på returveien |
For en kontrollert sjekk, bruk et endepunkt du selv drifter som registrerer eller returnerer de mottatte forespørselsheaderne. Gi forespørselen en gjenkjennelig markør slik at opphavets post kan knyttes til den bestemte klientoperasjonen.
I et program basert på WebClient beskriver ResponseHeaders svaret som returneres. Det er ikke en registrering av proxens forespørsel til destinasjonen. En server kan velge å ekkoe forespørselsinformasjon i svarteksten, men det er applikasjonsatferd.
Hvis banen inneholder flere mellomledd, ser destinasjonen deres samlede videresendingseffekter. Bare tilstedeværelsen av en header tilskriver ikke en endring til ett bestemt hopp. For egendefinerte API-felt forklarer reglene for videresending og Connection-feltet når endring forventes.
En vanlig HTTPS CONNECT-tunnel legger til en annen grense: den indre HTTP-forespørselen er kryptert mellom klienten og nettstedet. En relay-proxy kan ikke redigere disse krypterte headerne. Headere i CONNECT-utvekslingen tilhører den separate utvekslingen, mens en administrert TLS-inspeksjonsproxy har en annen rolle.