Forbindelsen åbnes. Anmodningsheadere forsvinder. Filen ser ikke ud til at flytte sig. En forklaring er, at klienten venter på et svar på Expect: 100-continue, før den sender sin body.

Mekanismen lader modtageren afvise en anmodning ud fra dens headere, før en potentielt stor upload sendes. Den sædvanlige vellykkede sekvens er:

request headers → 100 Continue → request body → final response

100 er informativ: den tillader klienten at fortsætte, men betyder ikke, at filen er gemt, eller at applikationens handling er lykkedes. Et Git push, der returnerer HTTP 417, er et konkret tilfælde af en fejlet forventning.

Find ud af, hvilket svar klienten modtog

ObservationBetydning, der skal undersøges
100 ContinueKlienten kan fortsætte med bodyen
Endelig afvisning før bodyenHandlingen blev afvist i headerfasen
Intet forventet midlertidigt svarKlientens ventepolitik og håndteringen på den vej

curl har en særlig indstilling for ventetid på expect-continue. Hvis den libcurl-ventetid udløber uden det forventede svar, sender den bodyen alligevel; udløb er ikke automatisk en mislykket hel overførsel. Indstillingen er adskilt fra den tid, der er tilladt til den fuldstændige overførsel. At øge sidstnævnte kan efterlade den samme indledende pause uforklaret.

Identificer også, hvilken HTTP-samtale der bærer Expect. Ved almindelig CONNECT til en HTTPS-destination foregår webstedets upload-udveksling inde i TLS; forward-proxyen undersøger ikke bare dens indre forventningsheader. En intercept- eller klartekst-videresendelsesvej er anderledes.

At fjerne forventningen kan være et bevidst kompatibilitetsvalg, men det betyder, at klienten kan begynde at sende en stor body, før den hører om en tidlig afvisning. Sammenlign den adfærd med det faktiske krav. Beskriv ikke en historisk omvej for en gammel proxy som en universel instruktion om at fjerne headeren fra enhver upload.

Relaterede artikler