要約

  • draft-ietf-httpbis-connect-tcp-14 は、target_host と target_port を含む URI Template を TCP プロキシサービスの設定単位にする。
  • 展開後の URI は、プロキシの origin、経路、認証空間、宛先ポリシーを一つの入口に集める。そのためテンプレートの由来と変数制約も認可判断の一部になる。
  • IETF Last Call は 2026 年 10 月 1 日までである。現時点では Internet-Draft であり、RFC の承認、実装、導入、配送結果を示す証拠ではない。

入口の文字列が権限を持つ

従来の HTTP CONNECT では、トンネル先のホスト名とポートが前面に出る。CONNECT-TCP revision 14 では、その二つを target_host と target_port として URI Template に展開し、生成された URI を connect-tcp Capsule Protocol 接続の宛先にする。

この URI は単なる表示形式ではない。どの HTTP origin が要求を受けるか、どのパスをゲートウェイが選ぶか、どの protection space の資格情報を使うか、HSTS や Alt-Svc、Cookie などの origin 単位の状態がどこに作用するかを決める。

草案は RFC 9298 の検証規則を参照する。テンプレートは絶対形式で、scheme、authority、path が空でなく、変数は path または query に置かれ、二つの対象変数を含まなければならない。危険になり得る展開演算子にも制限がある。違反を検出したクライアントは、要求を送る前に設定を拒否する。

これは強い構文上の境界である。しかし、テンプレートを配布した主体が正当か、その主体に出口を変更する権限があるか、指定された origin が意図した管理ドメインに属するかは証明しない。正しく展開された悪い設定は、なお悪い設定である。

HTTPの応答は接続の段階を示す

HTTP/1.1 では、クライアントは展開した URI に GET を送り、Upgrade: connect-tcp を要求する。要求が適正で許可される場合、プロキシは最終応答の前に宛先 TCP 接続を試す。成功すれば 101 Switching Protocols を返す。接続していないのにプロトコルを切り替えてはならない。

HTTP/2 と HTTP/3 では、プロキシが extended CONNECT の利用可能性を通知し、クライアントは :protocol = connect-tcp を使う。:authority はプロキシ、:path と :scheme はテンプレートから得た URI を表す。成功応答の後、そのストリームで capsule が運ばれる。

Expect: 100-continue は証拠の粒度をさらに明確にする。100 Continue は「要求を受信し、ただちには拒否しなかった」という中間状態であり、宛先との TCP ハンドシェイクを待たない。後の 101 や成功した extended CONNECT は、プロキシが TCP 接続を確立したと報告する。それでも接続先アプリケーションの身元、TLS 証明書の受理、ペイロードの配送、処理の完了は別である。

したがって「プロキシ成功」という一語の監視項目では足りない。入口での拒否、DNS やポリシー後の接続失敗、接続後のアプリケーション失敗は別々に記録すべきである。

認証されるのはプロキシの保護空間

テンプレート駆動型プロキシは明確な HTTP origin を持つため、通常は 401、WWW-Authenticate、Authorization を使う。古典的な 407 系を使わないのは、それらが通常の HTTP gateway を越えないからだ。一つのテンプレートから生成されたプロキシ資源は、同じ protection space を共有するとクライアントは想定する。

これにより、ゲートウェイでのパスルーティング、DDoS 対策、要求の正規化、利用者認可を再利用できる。高エントロピーのパスや concealed authentication で、権限のない探索者からサービスを見えにくくすることもできる。

しかし、プロキシ資格情報は接続先の権限まで運ばない。認証結果が答えるのは、その protection space に対して主体が条件を満たしたかどうかである。宛先ホストとポートを許すかはプロキシのポリシー、解決された IP の選択は接続処理、接続先 TLS の身元はトンネル内部、業務操作の許可はアプリケーションが決める。

RFC 9110 は、任意のポートへの CONNECT が意図しないプロトコルの中継に使われ得るため、安全な対象を制限するよう求めている。URI Template はこの危険を消さない。ポリシーを置く場所を明瞭にする。

FINを伝えても、仕事の完了にはならない

TCP のバイト列は DATA capsule に入る。FINAL_DATA は最後のデータを持てるうえ、その方向の TCP FIN に相当する。FINAL_DATA の後に DATA や別の FINAL_DATA を送ってはならない。TCP FIN を受けた側は FINAL_DATA を送り、有効な FINAL_DATA を受けた側は TCP FIN を送る。

一方、capsule の境界は TCP segment、TLS record、HTTP DATA frame、QUIC STREAM frame、アプリケーションメッセージの境界とは一致しない。中間装置は連続する capsule を分割・結合できるが、バイト順序と最後の閉鎖意味を保たなければならない。

共通仕様が保証しようとするのは、順序と方向別の閉鎖である。クライアントが HTTP ストリームへ書き込んだ事実は、接続先アプリケーションへの配送証明ではない。プロキシが TCP socket へ書いた事実も、相手が処理した証明ではない。FINAL_DATA は一方向の終了を表すが、逆方向の応答が完全に戻ったことを保証しない。

HTTP/2 と HTTP/3 の optimistic data は、選ばれた TCP 接続が書き込み可能になるまでプロキシが保持し、接続失敗時には破棄する。複数 IP を競合させる場合、採用しなかった接続にデータを送ってはならない。ここでも「送信」「選択」「配送」「処理」を一つにしてはいけない。

Last Callは最終結果ではない

IESG の告知 は、HTTPBIS から Proposed Standard としての審査依頼を受け、10 月 1 日まで意見を求めている。Datatracker は revision 14 を Active Internet-Draft、IESG 提出済み、Last Call 中と記録する。

これは手続きの位置を示す。RFC の成立、製品での実装、ゲートウェイ互換性、半閉鎖の相互運用、運用ポリシーの採用は示さない。将来 RFC になっても、実装と結果は別途観測しなければならない。

Running-code primacy の要点は、実際に結果を負うシステムから証拠を取ることにある。Minimum initial specification が示すように、共通層は構文、順序、閉鎖を狭く定義できる。テンプレートの信頼、対象ポリシー、資格情報、成功の定義は、結果を負う運用者の判断として残る。

プロキシはトンネルを許可できる。トンネルの向こう側の真実までは代行できない。

出典