Observer en proxys videresendte forespørgsel ved dens destination
Vælg det rigtige observationspunkt for headere, der tilføjes eller ændres, efter at klienten har sendt en HTTP-forespørgsel.
En klient forbereder en HTTP-forespørgsel, og en forward-proxy kan ændre meddelelsen, før den sendes videre. Destinationen er det sted, hvor den videresendte version bliver observerbar.
| Observationspunkt | Meddelelse tilgængelig der |
|---|---|
| Klientens forespørgselsobjekt | Forespørgslen, der er forberedt til det første hop |
| Oprindelsens forespørgselslog eller ekko-handler | Forespørgslen, der modtages efter videresendelsen |
| Klientens samling af svarheadere | Svaret, der modtages på returvejen |
Til en kontrolleret kontrol skal du bruge et endepunkt, du selv driver, som registrerer eller returnerer de modtagne forespørgselsheadere. Giv forespørgslen en genkendelig markering, så oprindelsens post kan knyttes til den bestemte klienthandling.
I et program baseret på WebClient beskriver ResponseHeaders det returnerede svar. Det er ikke en registrering af proxens forespørgsel til destinationen. En server kan vælge at ekkoere forespørgselsoplysninger i svarets krop, men det er applikationsadfærd.
Hvis stien indeholder flere mellemled, ser destinationen deres samlede videresendelseseffekter. Blot tilstedeværelsen af en header henfører ikke en ændring til et bestemt hop. For brugerdefinerede API-felter forklarer reglerne for videresendelse og Connection-feltet hvornår ændring forventes.
En almindelig HTTPS CONNECT-tunnel tilføjer endnu en grænse: den indre HTTP-forespørgsel er krypteret mellem klienten og webstedet. En relay-proxy kan ikke redigere de krypterede headere. Headere i CONNECT-udvekslingen hører til den særskilte udveksling, mens en administreret TLS-inspektionsproxy har en anden rolle.