A kapcsolat megnyílik. A kérés fejlécei elmennek. Úgy tűnik, a fájl nem mozdul. Az egyik magyarázat, hogy a kliens a Expect: 100-continue-ra vár válaszra, mielőtt elküldené a törzsét.

A mechanizmus lehetővé teszi a fogadó számára, hogy a kérést a fejlécei alapján utasítsa el, mielőtt egy esetleg nagy feltöltés elküldésre kerül. A szokásos sikeres sorrend:

request headers → 100 Continue → request body → final response

A 100 tájékoztató jellegű: engedi a klienst továbblépni, de nem jelenti azt, hogy a fájl tárolódott, vagy hogy az alkalmazás művelete sikerült. Egy HTTP 417-et visszaadó Git push az elvárás-hiba egy konkrét esete.

Állapítsa meg, milyen választ kapott a kliens

MegfigyelésVizsgálandó jelentés
100 ContinueA kliens továbbléphet a törzzsel
Végleges elutasítás a törzs előttA művelet a fejlécfázisban elutasításra került
Nincs várt köztes válaszA kliens várakozási szabályzata és a kezelés azon az útvonalon

A curl külön várakozási beállítást kínál az expect-continue számára. Ha ez a libcurl-várakozás a várt válasz nélkül jár le, a törzset akkor is elküldi; a lejárat nem jelent automatikusan sikertelen teljes átvitelt. A beállítás elkülönül a teljes átvitelre engedélyezett időtől. Utóbbi növelése ugyanazt a kezdeti szünetet hagyhatja megmagyarázatlanul.

Azt is állapítsa meg, melyik HTTP-beszélgetés hordozza az Expectet. Egy HTTPS-cél felé irányuló szokásos CONNECT esetén a webhely feltöltési cseréje a TLS-en belül van; az előre továbbító proxy nem egyszerűen vizsgálja a belső elvárás-fejlécét. Az elfogó vagy nyílt szöveges továbbítási útvonal más.

Az elvárás eltávolítása lehet szándékos kompatibilitási választás, de azt jelenti, hogy a kliens elkezdhet nagy törzset küldeni, mielőtt értesülne egy korai elutasításról. Hasonlítsa össze ezt a viselkedést a tényleges követelménnyel. Ne írja le egy régi proxyhoz készült történelmi kerülőutat általános utasításként arra, hogy minden feltöltésből távolítsák el a fejlécet.

Kapcsolódó cikkek