要約

  • RFC 9110 では、クライアントは同一接続上のプロトコル変更を招くため Upgrade を送ってよいが、サーバーは無視してよく、中継者は通常の転送前に接続固有のフィールドを取り除かなければならない。
  • 完了した切替の証拠には、提示された候補から選んだ有効な 101 Switching Protocols 応答、元のリクエストの送信完了、新プロトコルでの最初の有効な交換が必要になる。

ある移行ダッシュボードがリクエスト内の Upgrade: websocket を見つけ、即座に「WebSocket 有効」と記録したとする。ところがクライアントとオリジンの間のプロキシは Connection の指定に従い、ホップ固有の招待を削除した。オリジンはそれを一度も見ず、HTTP/1.1 の通常の 200 OK を返す。どちらの端点もプロトコルを変えていないのに、ダッシュボードは提案を結果として数えてしまう。

これは仮想的な制御不全であり、特定のサービスを報告するものではない。片側で観測したヘッダーだけを、境界の両側にまたがる順序付き事実が必要な状態遷移の証明に使うことが誤りである。

RFC 9110 は Upgrade を、同じ接続上で HTTP/1.1 から別のプロトコルへ移る仕組みとして定義する。クライアントは優先順に並べたプロトコルの一覧を送り、切替を招いてよい。サーバーはその招待を無視してよい。したがってフィールドが表すのは意思と選好であり、受諾、交渉成功、展開範囲、アプリケーションの準備完了ではない。

招待は接続固有でもある。Upgrade の送信者は Connection にも upgrade を含めなければならない。この規則により、中継者は受け取ったオプションをエンドツーエンドの情報として無条件に転送しない。中継者は Connection が指名したフィールドを除去する。要求されたプロトコルに対応するプロキシが次のホップにも招待を出す場合は、新しいホップ固有の Upgrade を生成でき、その転送メッセージ自身の Connection に upgrade を含めなければならない。クライアント境界の記録だけでは、オリジンが同じ提案を受けたとは証明できない。HTTP/1.0 サーバーが Upgrade を受信した場合は無視しなければならない。

有効な受諾にはさらに厳しい形がある。切り替えるサーバーは 101 Switching Protocols と、選択したプロトコルを示す Upgrade フィールドを送らなければならない。クライアントが提示しなかったプロトコルを選んではならない。101 は判断境界である。それ以前はクライアントの提案にすぎず、有効な応答以後に初めて両者は同一接続を新しい規則で解釈することに合意する。

それでも 101 一行だけでは受領証は完成しない。クライアントは招待を含むリクエストを完全に送り終えるまで、新プロトコルを使い始められない。受け取ったメッセージの意味を新プロトコルが保てない場合、サーバーは切り替えてはならない。切替後、サーバーは元のリクエストへの応答を継続し、新プロトコル内で HTTP 応答と同等の形を取ることが期待される。必要なのはリクエスト完了境界と、新プロトコルで正しく構成された最初の交換である。

この仕組みは下位のトランスポートを交換せず、別接続も作らない。既存接続の最上位アプリケーションプロトコルだけが変わる。異なる接続上の提案と 101 やフレームを結べば、規格が記述しない遷移を捏造することになる。接続識別子、バイト順序、観測方向が不可欠だ。

本稿は、Via の網羅性を扱う R067、Alt-Svc と代替経路を扱う R064、優先度復旧を扱う Strategic Local、一時 IPv6 識別子の相関を扱う B842 と異なる。対象は単一接続に束縛されたアプリケーションプロトコル切替であり、証拠は交渉と交換を並べた受領証である。

信頼できる受領記録は、正確なリクエスト、順序付き候補、Connection トークン、各中継者の前後の観測、最終ステータス、選択プロトコル、リクエスト終端、切替位置、新プロトコルの最初の有効メッセージ、フォールバックまたは切断を結合する。この記録は IETF が定義するプロトコル要素ではなく、運用証拠を編集上まとめたものである。「提案を観測」と「切替完了」を同じ値に正規化してはならない。

出典