要約

  • RFC 2295 は、一つの HTTP URI に結び付いた複数の表現を機械可読なバリアント一覧で可視化した。ただし、一覧応答そのものに各バリアントのデータは含まれなかった。
  • 選択、取得、表示は別の段階だった。条件を満たせばサーバーが選択済みの表現を返せる一方、クライアントが一覧から選んで取得することもできた。

一つのリソースに複数の答え

1990年代の終わりごろ、Web はすでに実務上の食い違いに直面していた。同じリソースでも HTML 版と PostScript 版、英語版とフランス語版があり、ユーザーエージェントの能力によって適切な版は違う。公開者は版ごとに異なる URL を用意することも、一つの URI の背後で複数の版を交渉することもできた。難題は版を選ぶことだけではない。キャッシュなどの中継者も、どの応答がどの要求に対応するかを区別しなくてはならなかった。

1998年3月の RFC 2295「Transparent Content Negotiation in HTTP」は、候補を見えるようにする実験的な仕組みを提示した。規格は個々の版を variant と呼び、それぞれの機械可読な説明を一つの交渉可能なリソースに結び付ける。Alternates ヘッダーには候補の URI と、メディアタイプ、言語、ソース品質、機能などの属性を記述できた。「透明」とは、オリジンサーバー内にある全バリアントを外部の当事者から見えるようにする意味だった。すべてのブラウザーが自動で交渉することや、選択の過程が見えなくなることを意味しない。

この仕組みが定義した交渉の軸は四つある。メディアタイプ、文字セット、言語、そして機能だ。四つ目は、最初の三つでは表せない性質、たとえば HTML 拡張や形式固有の能力を扱うために加えられた。圧縮などのコンテンツ符号化は別の直交する処理で、この仕組みの第五のバリアント軸ではない。RFC 2295 が記述しようとしたのは、どの表現が適切かであり、サーバーがバイト列に施すあらゆる変換ではなかった。

三つの受け渡し記録

一覧応答が返すのは目録だ。RFC 2295 の定義では、バリアント一覧を返すが、バリアントのデータは返さない。透明ネゴシエーションに対応するユーザーエージェントは候補を評価し、バリアント URI に通常の HTTP 要求を送って取得できる。RFC の例はこの差をはっきり見せる。まずサーバーが一覧を返し、その後クライアントが paper.1 を要求する。論文を含むのは二度目の応答だ。300 Multiple Choices の応答には、人が手動で選べる本文を付けることもできる。その場合も、一覧自体が選択された表現になるわけではない。

サーバーも単なるカタログ係ではない。choice response は最良と判断されたバリアントの表現を返し、一覧も併せて返せる。ただしサーバーがユーザーエージェントに代わって判断するには十分な情報が必要で、選ばれたバリアントは RFC の URI 上の近接条件を満たさなければならない。姉妹文書の実験的 RFC 2296 は、遠隔選択アルゴリズムを規定した。最良候補が正の明確な品質を持つと判断できない場合や近接条件を満たさない場合、アルゴリズムは選択応答ではなく一覧を返す。クライアントが独自のローカルアルゴリズムを使うこともあり、一覧が応答に含まれていれば、サーバーとは別の候補を取得できた。

したがって、この歴史を「クライアントが選ぶ仕組み」とだけ説明するのは正確でない。クライアントが選ぶ場合も、サーバーが代わりに選ぶ場合もあった。プロトコルは、候補の目録、判断を担う主体、データを運ぶ応答、その後の表示を別々に扱った。サーバーから見て、ユーザーエージェントが Negotiate ヘッダーを送ることは透明ネゴシエーションの対応を示す。しかし、能力を示す宣言は、特定の要求が実際にその仕組みを使ったという記録ではない。

キャッシュも設計の一部

ネゴシエーションによって、一つの URI から異なる表現が返ることがある。キャッシュがそれらを取り違えれば、選択アルゴリズムが正しくても結果は誤る。このため RFC 2295 は HTTP の Vary とエンティティタグを使い、バリアント一覧用の検証子も加えた。choice response から通常の応答をキャッシュが取り出す方法や、選ばれたリソースの位置を交渉可能なリソースとどう結び付けるかも定めた。キャッシュの正しさは周辺的な実装事項ではなく、URI を再利用できるようにする契約の一部だった。

設計にはコストもあった。毎回の要求で好みをすべて送るとヘッダーが大きくなるため、ユーザーエージェントは一覧をローカルで調べることが多かった。一方、Accept に表れる好みから、使っているソフトや環境の特徴が漏れることもある。RFC はプライバシー情報の露出、バリアント資源からの応答偽装、ネゴシエーションによって明らかになるセキュリティ上の穴を明示的に扱った。ここで確認できるのは設計上の懸念であって、特定の事故が起きた証拠ではない。

RFC 2295 は Experimental と明記され、Internet Standard を定めるものではないと述べている。また、この透明ネゴシエーションの対象は GET と HEAD であり、すべての HTTP トランザクションではなかった。規格から読み取れるのは、候補を点検可能にしつつ、判断をクライアント、サーバー、キャッシュに分ける構想である。今回確認した資料は、ブラウザーの対応調査、導入率、利用者の成果を立証していない。広告されたバリアントが必ず取得されるとは限らず、応答を受け取っただけでは人が画面で何を見たかは分からない。

出典