HTTP-alsupraj paŭzoj kaj Expect: 100-continue
Rekonu la interŝanĝon Expect: 100-continue kaj distingi ĝian mallongan decidpunkton disde alŝuto, kiu haltis dum transigo de datumoj.
La konekto malfermiĝas. La petaj kaplinioj foriras. Ŝajnas, ke la dosiero ne moviĝas. Unu klarigo estas, ke la kliento atendas respondon al Expect: 100-continue antaŭ ol sendi sian korpon.
La mekanismo ebligas al ricevanto malakcepti peton laŭ ĝiaj kaplinioj antaŭ ol eble granda alŝuto estas sendita. La kutima sukcesa sinsekvo estas:
request headers → 100 Continue → request body → final response100 estas informa: ĝi permesas al la kliento daŭrigi, sed ne signifas, ke la dosiero estis konservita aŭ ke la aplika operacio sukcesis. Git push redonanta HTTP 417 estas unu konkreta kazo de malsukcesinta atendo.
Trovu, kiun respondon la kliento ricevis
| Observo | Signifo por esplori |
|---|---|
| 100 Continue | La kliento povas daŭrigi kun la korpo |
| Fina malakcepto antaŭ la korpo | La operacio estis rifuzita en la kaplinia fazo |
| Neniu atendata intera respondo | La atendpolitiko de la kliento kaj la traktado sur tiu vojo |
curl havas apartan atendan agordon por expect-continue. Se tiu libcurl-atendo finiĝas sen la atendata respondo, ĝi sendas la korpon tamen; fino ne estas aŭtomate malsukcesa tuta transigo. La agordo estas aparta de la tempo permesita por la kompleta transigo. Pliigi la lastan povas lasi la saman komencan paŭzon neklarigita.
Identigu ankaŭ, kiu HTTP-konversacio portas Expect. Ĉe ordinara CONNECT al HTTPS-celo, la alŝuta interŝanĝo de la retejo estas ene de TLS; la antaŭa prokuro ne simple inspektas ĝian internan atendaĵan kaplinion. Interkapta aŭ platteksta plusenda vojo estas malsama.
Forigi la atendo povas esti intenca kongruec-elekto, sed ĝi signifas, ke la kliento povas komenci sendi grandan korpon antaŭ ol scii pri frua malakcepto. Komparu tiun konduton kun la fakta postulo. Ne priskribu historian solvon por malnova prokuro kiel universalan instrukcijon forigi la kaplinion el ĉiu alŝuto.