Yhteys avautuu. Pyynnön otsakkeet lähtevät. Tiedosto ei näytä liikkuvan. Yksi selitys on, että asiakas odottaa vastausta Expect: 100-continue-otsakkeeseen ennen runkonsa lähettämistä.

Mekanismi antaa vastaanottajan hylätä pyynnön otsakkeidensa perusteella ennen kuin mahdollisesti suuri lataus lähetetään. Tavallinen onnistunut järjestys on:

request headers → 100 Continue → request body → final response

100 on informatiivinen: se sallii asiakkaan jatkaa, mutta ei tarkoita, että tiedosto on tallennettu tai sovelluksen toiminto onnistui. Git push, joka palauttaa HTTP 417, on yksi konkreettinen odotuksen epäonnistumistapaus.

Selvitä, minkä vastauksen asiakas sai

HavaintoSelvitettävä merkitys
100 ContinueAsiakas voi jatkaa rungon kanssa
Lopullinen hylkäys ennen runkoaToiminto hylättiin otsakevaiheessa
Ei odotettua väliaikaista vastaustaAsiakkaan odotuskäytäntö ja käsittely kyseisellä polulla

curl tarjoaa erillisen odotusasetuksen expect-continuelle. Jos tuo libcurl-odotus päättyy ilman odotettua vastausta, se lähettää rungon silti; päättyminen ei ole automaattisesti koko siirron epäonnistuminen. Asetus on erillinen täydelle siirrolle sallitusta ajasta. Jälkimmäisen kasvattaminen voi jättää saman alkuvaiheen tauon selittämättä.

Selvitä myös, mikä HTTP-keskustelu kuljettaa Expectiä. Tavallisessa CONNECTissa HTTPS-kohteeseen verkkosivuston latausvaihto on TLS:n sisällä; forward-välityspalvelin ei yksinkertaisesti tarkasta sen sisäistä odotusotsaketta. Sieppaus- tai selkokielinen välityspolku on erilainen.

Odotuksen poistaminen voi olla tarkoituksellinen yhteensopivuusvalinta, mutta se tarkoittaa, että asiakas voi alkaa lähettää suurta runkoa ennen kuin saa tietää varhaisesta hylkäyksestä. Vertaa tätä käyttäytymistä todelliseen vaatimukseen. Älä kuvaile vanhalle välityspalvelimelle tehtyä historiallista kiertotietä yleisenä ohjeena poistaa otsake jokaisesta latauksesta.

Aiheeseen liittyvät artikkelit