Observu la plusenditan peton de prokurilo ĉe ĝia celo
Elektu la ĝustan observejon por kapoj aldonitaj aŭ ŝanĝitaj post kiam la kliento sendas HTTP-peton.
Kliento preparas HTTP-peton, kaj antaŭa prokurilo povas ŝanĝi tiun mesaĝon antaŭ ol sendi ĝin plu. La celo estas la loko, kie la plusendita versio fariĝas observebla.
| Observejo | Mesaĝo disponebla tie |
|---|---|
| Peta objekto de la kliento | La peto preparita por la unua salto |
| Petprotokolo de la origino aŭ eĥa traktilo | La peto ricevita post plusendo |
| Responda kaparo de la kliento | La respondo ricevita sur la revena vojo |
Por kontrolita testado, uzu finpunkton, kiun vi mem funkciigas kaj kiu registras aŭ resendas la ricevitajn petokapojn. Donu al la peto rekoneblan markilon, por ke la origina registro povu esti ligita al la koncerna klienta operacio.
En aplikaĵo bazita sur WebClient, ResponseHeaders priskribas la resenditan respondon. Ĝi ne estas registro de la peto de la prokurilo al la celo. Servilo povas elekti eĥi petinformojn en sia responda korpo, sed tio estas aplikaĵa konduto.
Se la vojo enhavas plurajn perantojn, la celo vidas iliajn kuneigitajn plusendajn efikojn. La nura ĉeesto de kapo ne atribuas ŝanĝon al unu aparta salto. Por propraj API-kampoj, la reguloj pri plusendo kaj la kampo Connection klarigas, kiam ŝanĝo estas atendata.
Ordinara HTTPS CONNECT-tunelo aldonas alian limon: la interna HTTP-peto estas ĉifrita inter la kliento kaj la retejo. Relajsa prokurilo ne povas redakti tiujn ĉifritajn kapojn. Kapoj en la CONNECT-interŝanĝo apartenas al tiu aparta interŝanĝo, dum administrata TLS-inspekta prokurilo havas alian rolon.