Bekyk 'n instaanbediener se deurgestuurde versoek by sy bestemming
Kies die regte waarnemingspunt vir kopskrifte wat bygevoeg of verander word nadat die kliënt 'n HTTP-versoek stuur.
'n Kliënt berei 'n HTTP-versoek voor, en 'n deurstuur-instaanbediener kan daardie boodskap verander voordat dit verder gestuur word. Die bestemming is waar die deurgestuurde weergawe waarneembaar word.
| Waarnemingspunt | Boodskap wat daar beskikbaar is |
|---|---|
| Kliënt se versoekobjek | Die versoek wat vir die eerste sprong voorberei is |
| Oorsprong se versoeklog of eggo-hanteerder | Die versoek wat ná deursturing ontvang is |
| Kliënt se versameling responkopskrifte | Die respons wat op die terugpad ontvang is |
Vir 'n beheerde kontrole, gebruik 'n eindpunt wat jy self bedryf en wat die ontvangde versoekkopskrifte aanteken of terugstuur. Gee die versoek 'n herkenbare merker sodat die oorsprongrekord aan die betrokke kliëntebewerking gekoppel kan word.
In 'n toepassing op WebClient, ResponseHeaders beskryf die teruggekeerde respons. Dit is nie 'n aantekening van die instaanbediener se versoek aan die bestemming nie. 'n Bediener kan kies om versoekinligting in sy responsliggaam terug te eggo, maar dit is toepassingsgedrag.
As die pad verskeie tussengangers bevat, sien die bestemming hul gekombineerde deurstureffekte. Die blote teenwoordigheid van 'n kopskrif skryf nie 'n verandering aan een bepaalde sprong toe nie. Vir pasgemaakte API-velde verduidelik die deurstuur- en Connection-veldreëls wanneer wysiging verwag word.
'n Gewone HTTPS CONNECT-tonnel voeg nog 'n grens by: die innerlike HTTP-versoek word tussen die kliënt en die webwerf versleutel. 'n Aflos-instaanbediener kan daardie versleutelde kopskrifte nie wysig nie. Kopskrifte op die CONNECT-uitruiling behoort aan daardie aparte uitruiling, terwyl 'n bestuurde TLS-inspeksie-instaanbediener 'n ander rol het.