Besjoch it trochstjoerde fersyk fan in proxy by syn bestimming
Kies it krekte observaasjepunt foar headers dy’t tafoege of feroare wurde neidat de klant in HTTP-fersyk stjoert.
In klant makket in HTTP-fersyk klear, en in foarútproxy kin dat berjocht feroarje foardat it fierder stjoerd wurdt. De bestimming is it plak dêr’t de trochstjoerde ferzje waarnimber wurdt.
| Observaasjepunt | Berjocht dat dêr beskikber is |
|---|---|
| Fersysobject fan de klant | It fersyk dat foar de earste sprong klearmakke is |
| Fersyklog fan de oarsprong of echo-ôfhanneler | It fersyk dat nei it trochstjoeren ûntfongen is |
| Samling antwurdheaders fan de klant | It antwurd dat op de weromwei ûntfongen is |
Brûk foar in beheinde kontrôle in einpunt dat jo sels beheare en dat de ûntfongen fersykheaders fêstleit of weromstjoert. Jou it fersyk in werkenber marker sadat it oarsprongsrecord keppele wurde kin oan de bepaalde klantoperaasje.
Yn in applikaasje op basis fan WebClient beskriuwt ResponseHeaders it weromstjoerde antwurd. It is gjin fêstlizzing fan it fersyk fan de proxy nei de bestimming. In tsjinner kin kieze om fersyksynformaasje yn syn antwurdlichem wer te jaan, mar dat is applikaasjegedrach.
As it paad ferskate tuskenlizzers befettet, sjocht de bestimming har kombinearre trochstjoereffekten. Allinnich it bestean fan in header skriuwt in feroaring net oan ien bepaald sprong ta. Foar oanpaste API-fjilden ferklearje de regels foar trochstjoeren en it Connection-fjild, wannear’t in feroaring ferwachte wurdt.
In gewoane HTTPS CONNECT-tunnel foeget in oare grins ta: it ynnere HTTP-fersyk is fersifere tusken de klant en de webside. In relaisproxy kin dy fersifere headers net bewurkje. Headers yn de CONNECT-útwikseling hearre by dy aparte útwikseling, wylst in beheare TLS-ynspeksjeproxy in oare rol hat.