Obserbahan ang ipinasa ng proxy na kahilingan sa destinasyon nito
Piliin ang tamang punto ng pagmamasid para sa mga header na idinadagdag o binabago pagkatapos magpadala ng HTTP na kahilingan ang kliyente.
Naghahanda ang kliyente ng HTTP na kahilingan, at maaaring baguhin ng forward proxy ang mensaheng iyon bago ito ipasa. Ang destinasyon ang lugar kung saan nagiging mapapansin ang ipinasang bersyon.
| Punto ng pagmamasid | Mensaheng makukuha roon |
|---|---|
| Bagay ng kahilingan ng kliyente | Ang kahilingang inihanda para sa unang pagtalon |
| Talaan ng kahilingan ng pinagmulan o tagahawak ng echo | Ang kahilingang natanggap pagkatapos ng pagpasa |
| Koleksyon ng header ng tugon ng kliyente | Ang tugon na natanggap sa daan pabalik |
Para sa kontroladong pagsusuri, gumamit ng endpoint na ikaw mismo ang nagpapatakbo at nagtatala o nagbabalik ng mga natanggap na header ng kahilingan. Bigyan ang kahilingan ng makikilalang marka upang maiugnay ang talaan ng pinagmulan sa partikular na operasyon ng kliyente.
Sa isang aplikasyong nakabatay sa WebClient, ResponseHeaders inilalarawan ang ibinalik na tugon. Hindi ito talaan ng kahilingan ng proxy sa destinasyon. Maaaring piliin ng server na ulitin ang impormasyon ng kahilingan sa katawan ng tugon, ngunit gawi iyon ng aplikasyon.
Kung may ilang tagapamagitan ang daan, nakikita ng destinasyon ang pinagsamang epekto ng kanilang pagpasa. Ang pag-iral lamang ng header ay hindi nag-uugnay ng pagbabago sa isang partikular na pagtalon. Para sa mga custom na field ng API, ang mga tuntunin sa pagpasa at sa field na Connection ipinapaliwanag kung kailan inaasahan ang pagbabago.
Ang karaniwang HTTPS CONNECT na tunnel ay nagdaragdag ng isa pang hangganan: ang panloob na HTTP na kahilingan ay naka-encrypt sa pagitan ng kliyente at website. Hindi maaaring i-edit ng relay proxy ang mga naka-encrypt na header. Ang mga header sa palitan ng CONNECT ay nabibilang sa hiwalay na palitang iyon, samantalang may ibang papel ang pinamamahalaang proxy ng inspeksyon ng TLS.