HTTP įkėlimo pauzės ir Expect: 100-continue
Atpažinkite Expect: 100-continue mainus ir atskirkite jų trumpą sprendimo tašką nuo įkėlimo, kuris strigo perduodant duomenis.
Ryšys atsidaro. Užklausos antraštės išvyksta. Atrodo, kad failas nejuda. Vienas paaiškinimas yra tas, kad klientas laukia atsakymo į Expect: 100-continue prieš siųsdamas savo turinį.
Šis mechanizmas leidžia gavėjui atmesti užklausą pagal jos antraštes dar prieš išsiunčiant galimai didelį įkėlimą. Įprasta sėkminga seka yra:
request headers → 100 Continue → request body → final response100 yra informacinis: jis leidžia klientui tęsti, bet nereiškia, kad failas buvo išsaugotas ar kad programos operacija pavyko. Git push, grąžinantis HTTP 417, yra vienas konkretus lūkesčio nepavykimo atvejis.
Nustatykite, kokį atsakymą gavo klientas
| Stebėjimas | Ką reikėtų tirti |
|---|---|
| 100 Continue | Klientas gali tęsti su turiniu |
| Galutinis atmetimas prieš turinį | Operacija buvo atmesta antraščių etape |
| Nėra laukiamo tarpinio atsakymo | Kliento laukimo politika ir apdorojimas tame kelyje |
curl turi atskirą expect-continue laukimo nustatymą. Jei tas libcurl laukimas baigiasi be laukiamo atsakymo, jis vis tiek siunčia turinį; pasibaigimas savaime nėra viso perdavimo nesėkmė. Šis nustatymas atskirtas nuo visam perdavimui skirto laiko. Padidinus pastarąjį, ta pati pradinė pauzė gali likti nepaaiškinta.
Taip pat nustatykite, kuriame HTTP pokalbyje perduodamas Expect. Įprastai naudojant CONNECT į HTTPS paskirties vietą, svetainės įkėlimo mainai vyksta TLS viduje; perdavimo tarpinis serveris tiesiog neapžiūri vidinės lūkesčio antraštės. Perėmimo arba atviro teksto perdavimo kelias yra kitoks.
Lūkesčio pašalinimas gali būti sąmoningas suderinamumo pasirinkimas, tačiau tai reiškia, kad klientas gali pradėti siųsti didelį turinį dar nesužinojęs apie ankstyvą atmetimą. Palyginkite šį elgesį su faktiniu reikalavimu. Nekokyklite istorinio seno tarpinio serverio sprendimo kaip universalios instrukcijos šalinti antraštę iš kiekvieno įkėlimo.