要約

  • 1997年1月のRFC 2068は、通常は要求された資源と別の資源との関係を表すHTTPの Link フィールドを定めた。一つの応答で複数のリンクを示せて、HTMLの LINK 要素に近い意味を持つ。
  • 2010年10月のRFC 5988によれば、1999年6月のRFC 2616は実装経験が不足していたため、このフィールドを削った。削除後は位置付けが曖昧になったが、一部のユーザーエージェントでの利用や新しい用途が現れた。
  • RFC 5988はHTMLだけに依存しない型付きリンクの仕組みとしてフィールドを定義し直した。2017年10月のRFC 8288はそれを置き換え、HTTPヘッダーの Link を資源間の関係を運ぶ形式の一つとして残した。

ページの外を走るリンク

HTMLページの中にあるリンクは目で追いやすい。ブラウザーが本文や LINK 要素を読み、関係に応じて表示したり取得したりする。しかし、Webの資源がいつもHTMLで返るわけではない。同じ資源を別の形式で受け取ったプログラムには、HTML本文の中だけに記された関係は届かない。HTTP応答のフィールドなら、本文の形式を解釈する前に関係を伝えられる。

1997年1月のHTTP/1.1仕様RFC 2068は、その置き場を第19.6.2.4節で与えた。Link は二つの資源の関係、普通は要求された資源と別の資源との関係を述べる。一つのエンティティに複数の値を載せられる。rel は関係の種類、title は人向けの表示名、anchor は別の起点を指定する。文書はHTMLの LINK 要素と意味が対応すると書いた。ページに書ける道標を応答の封筒にも書けるようにしたのである。

置き場が変われば、読める相手も変わる。HTMLの印はHTMLを解釈する読者に届く。HTTPフィールドは応答そのものに添えられるので、本文が別の表現でも読める。フィールドが示すのは型の付いた関係であって、参照先の取得や表示を代わりに実行するものではない。その後の動作はアプリケーションが決める。

RFC 2068では Link は追加機能の節に置かれた。同じ周辺には、関係を作ったり消したりする要求メソッド LINK と UNLINK もあった。ただしメソッドと応答フィールドは別の仕組みである。2010年に戻ったのは後者の定義だ。「リンク」という語が同じだからといってメソッドの復活まで語ると、規格の履歴を取り違える。

1999年版に残った空席

1999年6月のRFC 2616はRFC 2068を置き換えたが、Link フィールドの定義を収めなかった。その理由を後の RFC 5988が明記している。実装経験が不足していたため削除された。発想が文章として整っていても、HTTP/1.1の次の基本文書に残すだけの現場の材料がそろっていなかった。

これは規格編者の判断の記録であり、1999年に世の中の全サーバーやブラウザーがどう動いたかの統計ではない。製品ごとの送受信を知るには、日付付きの実装記録や保存されたHTTP応答が必要だ。ただ、仕様に一度載った機能でも実装の裏付けが薄ければ次の版から外れることは、この記録だけで確かめられる。

削除には別の費用もあった。RFC 5988は、フィールドの地位が不明確になり、汎用の Link を再利用せず用途ごとに専用ヘッダーを作ろうとする動きがあったと述べる。同じ種類の関係が、アプリケーション別の名前に分かれていくおそれがある。HTMLでない表現を受け取ったとき、資源どうしのつながりをどこから読むのかという問題は残ったままだった。

2010年の文書は、その後に一部のユーザーエージェントがフィールドを実装したことも記す。例に挙がるのはスタイルシートで、ほかの利用例も現れたという。「一部」という記述から全ブラウザーへの普及率は計算できない。しかし、再検討に使える実例と需要が増えたことは分かる。

戻ったリンクはHTMLに縛られない

2010年10月のRFC 5988は、古い定義と互換性を保ちつつ構文を更新して Link を定義し直した。核となるのは、リンクを特定の記述形式から切り離すことだ。型付きリンクには文脈となる資源、関係の種類、参照先、任意の参照先属性がある。同じ関係をHTML、Atom、HTTPヘッダーで運べる。形式は入れ物であり、関係そのものではない。

一つの資源に複数の表現がある場合、この違いは実務に効く。関係がHTML版の本文にだけ隠れていれば、別の形式を受け取るクライアントは手掛かりを失う。応答ヘッダーなら本文の形式を問わず一緒に渡せる。一方でHTML本文のリンクもHTMLの読者に役立つ。規格は双方に共通する形を示し、どちらをどう使うかはアプリケーションに委ねた。

RFC 5988はAtom由来のリンク関係登録簿も広げ、HTMLで知られた関係を取り込んだ。登録された関係名は資源間の意味を述べる。名前が付いたからといって参照先が必ず取得可能になったり、すべてのクライアントが自動的に動いたりはしない。ブラウザーがスタイルシートを探す一方、別の道具がライセンスや別版を探すこともある。共通なのは語彙であり、動作ではない。

2017年10月のRFC 8288はRFC 5988を置き換え、文脈、関係、参照先、任意の属性という構造を継いだ。HTTPの Link はリンクを表す方法の一つとして残る。文書は、WebブラウザーならHTMLの stylesheet を探し、HTTPヘッダーでも任意に探せることと、Atomのアプリケーションが別の関係を使うことを区別する。関係の種類は二つの資源の結び付きであり、参照先を取得したときのメディア形式とは違う。

1997年の段落を2010年にそのまま戻した、という話ではない。最初はHTMLのリンクに似た情報をHTTPに置く提案だった。後の二つの文書は、複数の形式をまたぐ関係のモデルと登録の手続きを備えた。戻ってきたフィールドには、以前より明確な仕事が与えられた。

規格はもう一組の足跡を待った

出版と普及を同じ出来事とみなすと、この経過は気まぐれに見える。1997年には定義できる提案があった。1999年には新しい基本仕様へ残すだけの実装経験が足りなかった。2010年には限定的な実装と新しい用途を示せるようになり、2017年には後継の規格へ進んだ。紙の上の地位を変えるのは編者だが、その判断の材料を増減させるのは稼働するプログラムだ。

争点はヘッダー名だけではない。HTML本文内のリンクはその表現に付随する。HTTP応答で運ぶ関係なら、本文が別形式でも読者に届く余地がある。すべての資源をHTMLページの形に押し込まずに、発行者と読者が型付きの関係を交換できる。

特定の製品がいつ送受信を始めたかをたどるには、日付付きの実装資料や応答記録が要る。RFCの連なりだけでも制度上の転回は示せる。一度定義され、経験不足で外されたフィールドが、ページの外で資源を結ぶ必要に応じて、より一般的なモデルとともに戻った。