HTTP-opplastingspauser og Expect: 100-continue
Gjenkjenn Expect: 100-continue-utvekslingen og skill det korte beslutningspunktet fra en opplasting som stoppet under dataoverføringen.
Tilkoblingen åpnes. Forespørselshodene går ut. Filen ser ikke ut til å bevege seg. En forklaring er at klienten venter på et svar på Expect: 100-continue før den sender kroppen.
Mekanismen lar en mottaker avvise en forespørsel ut fra hodene før en potensielt stor opplasting sendes. Den vanlige vellykkede sekvensen er:
request headers → 100 Continue → request body → final response100 er informativ: den lar klienten fortsette, men betyr ikke at filen er lagret eller at applikasjonsoperasjonen har lykkes. En Git push som returnerer HTTP 417, er ett konkret tilfelle av mislykket forventning.
Finn hvilket svar klienten fikk
| Observasjon | Hva som bør undersøkes |
|---|---|
| 100 Continue | Klienten kan fortsette med kroppen |
| Endelig avvisning før kroppen | Operasjonen ble avvist i hodestadiet |
| Ingen forventet mellomsvar | Klientens ventepolicy og håndteringen på den veien |
curl har en egen innstilling for expect-continue-venting. Hvis den libcurl-ventingen utløper uten det forventede svaret, sendes kroppen likevel; utløp er ikke automatisk en mislykket hel overføring. Innstillingen er atskilt fra tiden som er tillatt for hele overføringen. Å øke sistnevnte kan la den samme innledende pausen stå uforklart.
Identifiser også hvilken HTTP-samtale som bærer Expect. Med vanlig CONNECT til et HTTPS-mål ligger nettstedets opplastingsutveksling inne i TLS; videresendingsproxien inspiserer ikke bare den indre forventningsheaderen. En avskjærings- eller klartekstvei er annerledes.
Å fjerne forventningen kan være et bevisst kompatibilitetsvalg, men det betyr at klienten kan begynne å sende en stor kropp før den får vite om en tidlig avvisning. Sammenlign denne oppførselen med det faktiske kravet. Ikke beskriv en historisk løsning for en gammel proxy som en universell instruks om å fjerne headeren fra hver opplasting.