要約

  • Expect: 100-continue は本文を一時保留する意図を示し、メソッド、対象、ヘッダーだけで決まる最終拒否を先に返せるようにする。
  • 100は送信継続を促すだけで、オリジンは本文処理後の最終状態をなお返す。中継者が仮応答を生成する場合もある。
  • クライアントは待機を打ち切って本文を送れる。古い中継者が1xxを落としても、最適化が相互待ちへ変わらない。

高価な部分より先に判断材料が届く

HTTPでは要求行とヘッダーが、任意の本文より前に届く。認証不足、許可されないメソッド、誤った対象は、ファイル全体を受け取らずに判定できる。

すべて即座に送れば401や405の前に帯域を浪費する。一方、共通規則なしで止まれば、クライアントは許可を待ち、サーバーは本文を待つ。100はこの隙間を扱った。

1997年の RFC 2068 は情報状態100と、HTTP/1.0経路を含む複雑な互換動作を定めた。古い中継者が仮応答を運ばない可能性は、最初から待機を無条件にできない理由だった。

Expectが待っている事実を可視化した

RFC 2616 は Expect と 100-continue を導入した。サーバーは、本文を保留するクライアントと、すでに連続送信しているクライアントを区別できるようになった。

待つつもりなら明示し、本文がなければ使わない。本文の一部または全部がすでに届けば、サーバーは役目を失った100を省略できる。

完全なHTTP/1.1ヘッダー、本文の予告、期待を受けたオリジンは直ちに動く。ヘッダーで最終判断できればそれを返し、できなければ本文を待たず100を返す。許可が、許可対象の到着に依存してはならない。

続行は成功を意味しない

1xxは交換を終えない。100を送ったサーバーは、接続が早期終了しない限り、本文を受信・処理した後に最終状態を返す。

意味は狭い。現時点の情報に送信を止める理由がないだけで、認証、内容の妥当性、永続保存、メソッド実行、成功のいずれも保証しない。

したがって二段階コミットの準備票ではない。仮応答が管理するのはネットワーク支出であり、操作の確定ではない。

プロキシは勧められても受理を代行できない

プロキシは自分で判断できる最終状態を返すか、ヘッダーを先へ送る。次の相手が古いと知っていれば、自ら100を生成して進行を促すこともある。

その100は当該区間の通過許可であり、オリジンが要求を見た証拠ではない。送信元ホップを失った記録は、局所的な許可を端点の受理へ誤変換する。

417は経路が期待を満たせないことを示し、期待なしの再試行を促す。しかし副作用を持つメソッドの反復まで安全にはしない。何がオリジンへ届いたかは別に確認する必要がある。

沈黙に無期限の拒否権を与えない

RFC 7231 と RFC 9110 は、待機時間を固定せず、100がなくても本文を送れるとする。無期限に待つべきではない。

古い中継者は1xxを消すかもしれず、サーバーはすでに本文を読み始めているかもしれない。クライアント側の時間切れは、多少の無駄と引き換えに進行を守り、沈黙を統制権にしない。

全経路に共通する本文サイズや遅延の境界はない。小さな本文では追加の往復が損になる。仕様が定めるのは責任分担であり、普遍的な性能結論ではない。

早い最終応答の後にも境界処理が残る

本文送信中に最終状態が来ることがある。サーバーは接続を閉じるか、残りを読み捨てて後続メッセージの境界を守る必要がある。

アプリケーション判定と接続処置は別である。残存バイトの意味を双方が違えて理解すると、再利用接続で旧本文が次の要求に見える。

資料と限界

閉じた資料は RFC 2068、RFC 2616、RFC 7231、RFC 9110 である。歴史と意味を示すが、現在の普及、既定待機時間、節約量、中継実装は測らない。