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 klargjør en HTTP-forespørsel, og en videresendende proxy kan endre meldingen før den går videre. Destinasjonen er stedet der den videresendte versjonen blir observerbar.
| Observasjonspunkt | Melding som er tilgjengelig der |
|---|---|
| Klientens forespørselsobjekt | Forespørselen som er klargjort for det første hoppet |
| Opphavets forespørselslogg eller ekko-behandler | Forespørselen som mottas etter videresending |
| Klientens samling av svarheadere | Svaret som mottas på returveien |
For en kontrollert sjekk kan du bruke et endepunkt du drifter selv, som registrerer eller returnerer de mottatte forespørselsheaderne. Gi forespørselen en gjenkjennelig markør, slik at oppføringen hos opphavet kan knyttes til den aktuelle klienthandlingen.
I en applikasjon basert på WebClient beskriver ResponseHeaders svaret som returneres. Det er ingen registrering av proxyns forespørsel til destinasjonen. En server kan velge å gjenta forespørselsinformasjon i svarteksten, men det er applikasjonens atferd.
Har banen flere mellomledd, ser destinasjonen deres samlede videresendingseffekt. Bare at en header finnes, knytter ikke en endring til ett bestemt hopp. For egendefinerte API-felt forklarer reglene for videresending og Connection-feltet når en endring er ventet.
En vanlig HTTPS CONNECT-tunnel legger til nok en 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 hører til den separate utvekslingen, mens en administrert TLS-inspeksjonsproxy har en annen rolle.