HTTP üleslaadimise pausid ja Expect: 100-continue
Tuvastage Expect: 100-continue vahetus ja eristage selle lühikest otsustuspunkti üleslaadimisest, mis jäi andmete edastamise ajal seisma.
Ühendus avaneb. Päringu päised väljuvad. Tundub, et fail ei liigu. Üks selgitus on see, et klient ootab enne keha saatmist vastust Expect: 100-continue-le.
Mehhanism võimaldab vastuvõtjal päring päiste põhjal tagasi lükata enne, kui saadetakse võimalikult suur üleslaadimine. Tavaline edukas järjekord on:
request headers → 100 Continue → request body → final response100 on informatiivne: see lubab kliendil jätkata, kuid ei tähenda, et fail on salvestatud või rakenduse toiming õnnestus. Git push, mis tagastab HTTP 417, on üks konkreetne ebaõnnestunud ootuse juhtum.
Tehke kindlaks, millise vastuse klient sai
| Tähelepanek | Uuritav tähendus |
|---|---|
| 100 Continue | Klient saab kehaga jätkata |
| Lõplik tagasilükkamine enne keha | Toiming lükati tagasi päiste etapis |
| Oodatud vahevastust ei ole | Kliendi ootepoliitika ja käsitlemine sellel teel |
curl pakub expect-continue jaoks eraldi oote seade. Kui see libcurl oote aegub ilma oodatud vastuseta, saadab see keha siiski; aegumine ei ole automaatselt kogu edastuse ebaõnnestumine. Seade on eraldi kogu edastuse jaoks lubatud ajast. Viimase suurendamine võib jätta sama algse pausi selgitamata.
Tehke kindlaks ka see, milline HTTP vestlus Expect'i kannab. Tavalise CONNECT-i korral HTTPS-sihtkohta on veebisaidi üleslaadimisvahetus TLS-i sees; edastusproxy ei kontrolli lihtsalt selle sisemist ootusepäist. Kaaperdamise või avateksti edastamise tee on erinev.
Ootuse eemaldamine võib olla teadlik ühilduvusvalik, kuid see tähendab, et klient võib hakata suurt keha saatma enne, kui ta varajasest tagasilükkamisest teada saab. Võrrelge seda käitumist tegeliku nõudega. Ärge kirjeldage vana proxy jaoks mõeldud ajaloolist lahendust universaalse juhisena eemaldada päis igalt üleslaadimiselt.