HTTP-opplastingspausar og Expect: 100-continue
Kjenn att Expect: 100-continue-utvekslinga og skil det korte avgjerdsmomentet hennar frå ei opplasting som stoppa under dataoverføringa.
Tilkoplinga blir opna. Førespurnadshovuda går ut. Fila ser ikkje ut til å flytte seg. Ei forklaring er at klienten ventar på eit svar på Expect: 100-continue før han sender kroppen.
Mekanismen lèt ein mottakar avvise ein førespurnad ut frå hovuda før ei potensielt stor opplasting blir send. Den vanlege vellukka sekvensen er:
request headers → 100 Continue → request body → final response100 er informativ: han lèt klienten halde fram, men tyder ikkje at fila er lagra eller at applikasjonsoperasjonen har lukkast. Ein Git push som returnerer HTTP 417, er eitt konkret tilfelle av mislukka forventning.
Finn ut kva svar klienten fekk
| Observasjon | Kva som bør granskast |
|---|---|
| 100 Continue | Klienten kan halde fram med kroppen |
| Endeleg avvising før kroppen | Operasjonen vart avvist i hovudstadiet |
| Ikkje noko venta mellomsvar | Ventepolitikken til klienten og handteringa på den vegen |
curl har ei eiga innstilling for expect-continue-venting. Viss den libcurl-ventinga går ut utan det venta svaret, blir kroppen likevel send; utløp er ikkje automatisk ei mislukka heil overføring. Innstillinga er skild frå tida som er tillaten for heile overføringa. Å auke sistnemnde kan la den same innleiande pausen stå uforklart.
Identifiser òg kva HTTP-samtale som ber Expect. Med vanleg CONNECT til eit HTTPS-mål ligg opplastingsutvekslinga til nettstaden inne i TLS; videresendingsproxien granskar ikkje berre den indre forventningshovudet. Ein avskjerings- eller klartekstveg er annleis.
Å fjerne forventninga kan vere eit medvite kompatibilitetsval, men det tyder at klienten kan byrje å sende ein stor kropp før han veit om ei tidleg avvising. Samanlikn denne åtferda med det faktiske kravet. Ikkje skildre ei historisk løysing for ein gamal proxy som eit universelt pålegg om å fjerne hovudet frå kvar opplasting.