Tilkoblingen åpnes. Forespørselshodene sendes. Filen ser ikke ut til å røre seg. En mulig forklaring er at klienten venter på svar på Expect: 100-continue før den sender kroppen.

Mekanismen gjør at en mottaker kan avvise en forespørsel basert på hodene før en muligens stor opplasting sendes. Den normale vellykkede rekkefølgen er:

request headers → 100 Continue → request body → final response

100 er informativ: den gir klienten lov til å fortsette, men betyr ikke at filen er lagret eller at applikasjonsoperasjonen var vellykket. En Git push som svarer HTTP 417, er ett konkret eksempel på at forventningen ikke innfris.

Avklar hvilket svar klienten mottok

ObservasjonHva som må undersøkes
100 ContinueKlienten kan sende kroppen videre
Endelig avslag før kroppenOperasjonen ble avvist allerede ved hodene
Intet forventet mellomsvarKlientens ventestrategi og behandlingen langs denne veien

curl tilbyr en egen innstilling for venting på expect-continue. Dersom denne libcurl-ventingen løper ut uten det forventede svaret, sendes kroppen likevel; utløpet er ikke i seg selv en mislykket overføring. Innstillingen er atskilt fra tidsgrensen for hele overføringen. Å øke sistnevnte kan etterlate den samme innledende pausen uforklart.

Finn også ut hvilken HTTP-samtale som frakter Expect. Ved vanlig CONNECT mot et HTTPS-mål foregår nettstedets opplastingsutveksling inne i TLS; en videresendende proxy gransker ikke uten videre den indre forventningsheaderen. En vei med avlytting eller klartekst er noe annet.

Å fjerne forventningen kan være et bevisst kompatibilitetsvalg, men det innebærer at klienten kan begynne å sende en stor kropp før den får vite om en tidlig avvisning. Sammenlign denne oppførselen med det reelle kravet. Ikke framstill en historisk løsning for en gammel proxy som en allmenn instruks om å fjerne headeren fra alle opplastinger.

Relaterte artikler