要約

  • RFC 3205はHTTPの再利用を、相互運用性や安全性が自動で手に入る近道ではなく、既存の挙動を引き継ぐ設計判断として扱った。
  • 具体的な責任は設計者にある。サービスの識別、プロキシとの関係、キャッシュ、HTTPのエラーとアプリケーションの結果をどう分けるかを仕様に書くことだ。

取引相手はもう一者いた

2002年初頭、HTTPは新しいアプリケーションプロトコルにとって魅力的な道具箱だった。開発者は使い方を知り、ブラウザーが対応し、クライアントとサーバーのコードも公開されていた。TLSや既存の認証機構を利用できる場合もある。組織がすでにWebサービスを運用していれば、同じ仕組みで試作できるように見えた。ファイアウォールを越えやすいことも利点として挙げられた。

Keith MooreによるBCP 56は、見えにくいもう一者を設計に登場させた。二つのアプリケーションの間にあるHTTPのエコシステム全体だ。リクエストはクライアントライブラリー、プロキシ、キャッシュ、ファイアウォール、アドレス変換器、Webサーバーを経て、アプリケーションのコードに届くかもしれない。それぞれが、既知のフィールドに対して汎用的な意味を適用する。一つの部品で作業を省いても、残りの部品がアプリケーション固有の意味を共有するわけではない。

この文書は適合規則ではなく助言として書かれた。RFC 2119の大文字の規範語を意図的に使っていない。したがって、あらゆるアプリケーションにHTTPを避けよという話ではない。選択に伴う総コストを見えるようにせよ、という提案だった。HTTPには永続接続、バイト範囲、コンテンツネゴシエーション、キャッシュなどの機能が積み重なっていた。重ねる側のアプリケーションが必要としない機能まで引き継ぎ、制限するための作業を負うこともある。小さく頻繁な取引ではTCPとHTTPのオーバーヘッドが効きうる一方、複数のやり取りを一つの永続接続で再利用すれば接続コストを薄められる。

馴染み深い状態コードが違う話をする

難しさが表れるのは、HTTPの成功とアプリケーションの結果が一致しない場合だ。プロキシは新しいアプリケーションを理解しなくても、通常のHTTPルールに従える。条件がそろえば、成功応答を保存して似たリクエストに返すこともある。エラー応答の本文を置き換えたり、説明を付け足したりすることもある。クライアントが受け取るHTTP応答は正しくても、そのアプリケーション上の意味は古くなったり、見えなくなったり、変わったりする。

RFC 3205は、HTTPのリクエスト行やヘッダーで検出されるエラーと、アプリケーションの本文が表す結果を分けた。本文の結果に汎用的な200や500を使うなら、有害なキャッシュをどう避けるか、エラー本文が加工された場合にどう動作するかを仕様に示さなければならない。プロキシによるキャッシュやエラー応答の変更に耐えられないプロトコルなら、HTTPを土台にするべきではない。問題は「HTTPの状態コードは悪い」ということではなく、二つの層が成功と失敗を別の基準で定義しうる点にある。

同じ境界はメソッドとメディアタイプにもある。コンテンツタイプは対象が何かを示すもので、受信側がどの処理を実行すべきかまでは決めない。操作は別途、明示する必要がある。新しいHTTPメソッドを定義しても、別サービスに専用ポートやURIスキームが必要かどうかまでは決まらない。

再利用はサービスの識別も選び直す

ポート80とhttp:は、運用者、ソフトウェア、利用者にとってすでに意味を持っていた。新しいサービスが別のデータ、コード、プロセス、トラフィック管理を必要とするなら、専用ポートを使う理由になりうる。幅広く使われ、設定や認証情報、プロビジョニングが異なるサービスなら、独自のURIスキームが適切かもしれない。これは名前の美しさではなく、運用上のサービス識別の問題だ。

ライブラリー自体も前提を持ち込む。専用のサービスURLをHTTPライブラリーに渡すため、クライアントがHTTP風のURLに変換する場合がある。その後、プロキシは絶対URLを見て通常のWebリクエストとして扱うかもしれない。ライブラリーがHTTP/1.1を送るとしても、その版表示をアプリケーションプロトコルがどう受け入れるかは別途決める必要がある。クライアント、サーバー、プロキシの関係を書くのは仕様の役割であり、再利用コードへの期待ではない。

つまり、再利用は仕事を別の場所へ移す。既存コードは最初の実装を速めても、その汎用動作がシステム境界の一部になる。独立した実装が増えれば、一つのクライアントにとっての近道が、キャッシュ規則やサーバーの想定と衝突する機会も増える。これはRFC 3205の設計論から導ける解釈であり、開発費を測った調査でも、特定のプロトコルの失敗を示す証拠でもない。

後継文書は問題の持続を示す

2022年、RFC 9205がBCP 56の後継としてRFC 3205を置き換えた。HTTPが二十年にわたって変化した後の文書は、別々のチームによるHTTP API実装、クライアントとサーバーの非同期な進化、拡張性、キャッシュ、状態、認証、Web閲覧との共存を扱う。この更新は設計問題が続いていたことを示すが、両文書への普遍的な準拠を証明するものでも、2002年の助言が後の実務をすべて予見したことを示すものでもない。

歴史上の教訓は限定的で実用的だ。プロトコルを再利用しても境界はなくならず、共有ソフトウェアの意味論へ仕事が移る。同じHTTPライブラリーを使う二つの実装でも、応答の意味について食い違うことはある。相互運用には、周囲のHTTP部品が何をしてよいか、アプリケーションが何を担うか、各結果をどの層が所有するかを明記する必要がある。

中間装置のアーキテクチャ用語はRFC 3234にある。当時のHTTP/1.1の背景はRFC 2616、RFC 3205が採用しなかった規範語の慣行はRFC 2119に示される。一次資料はRFC 3205、RFC Editorの記録、IETF Datatrackerの記録、RFC 9205、そのRFC Editorの記録である。