構文

[29] anchor 引数の値は URL です。

[30] RFC によれば値は RFC 3986 URI-Reference >>25 である必要があります。

[31] これは同じ資源の素片を指した URL であっても構いませんし、別の資源の URL であっても構いません。相対URLなら、解釈に当たり RFC 3986 に従って解決しなければなりません。なお、メッセージの本体で指定されている基底URL は適用されません。 >>25

[32] 従って、 Link: 欄の対象IRIと同じく、 HTTP ヘッダーの基底URLに対して相対と解釈されることになります。なお、 Web Linking の定義上文脈IRIは RFC 3987 IRI参照であり、また anchor 引数の値は RFC 3986 URI参照であるため、 (明記されていませんが) 適宜パーセント符号化して URI とする必要があります。また、 (明記されていませんが) URI-Reference としての構文的な制約だけでなく、 RFC 3986/RFC 3987 に規定された構文で表現されていない制約も適用されていると解釈するべきでしょう。

[407] RFC によると、この引数の値は " で括らなければなりません。 >>25

[408] 多くの RFC は引用符の扱いが不明瞭で、構文上と実際上・一般的な理解上の引用符の必要性が一致していないこともあります。しかし >>25 では他の引数で引用符の有無の両方の構文が区別されているところ、 anchor に関しては引用符ありの構文のみしか示されていないので、必ず使わなければならないようです。また、 quoted-pair は使えない構文となっています。同様の理由で RFC 2231 の拡張は使えないと解釈できます。

[410] anchor 引数が複数指定されている場合の意味と処理モデルは規定されていません。

[411] 他の引数は複数指定することが認められているものもあります。

既定値

[409] anchor 引数が省略された場合の文脈IRIの既定値は、その HTTP 要求の URL です。

[35] HTTP の状態符号や応答ヘッダーによっては、文脈IRIが「匿名」となることもあります。 >>25

[36] 例えば、 GET 要求に対する 404 応答の場合が該当します。 >>25

[405]

>>36 のように RFC には記述がありますが、この例は一般的には URL が「匿名」であるとは解釈されていないように思います。 OPTIONS メソッドなど Request-URI が指定されなくて良いような要求などは URL が定義されないのでしょうが・・・。そもそもそのような場合に相対URL はどう解釈したらよいのでしょう。少なくても RFC 3986 に従う限りそのような状況では解決できないと思うのですが、 RFC はその辺の問題には言及していません。

メモ

[15] 2002-10-20 (日) 07:02 Link:: anchor 属性ってのがよくわかりません。現資源でもリンク先資源でもないが、関係ある第3の資源を書けばいいんでしょうか?

[21] >>15 訳が間違っていたので直しました。 anchor パラメーターは始点アンカーを当該資源ではなく URI で示す他の資源 (当該資源の一部でも良い。) を表すのに示すようです。例えば、こんな風に使うのを想定していたのではないでしょうか。

Link: <#section2>; anchor="#section1"; rel="next"
Link: <#section3>; anchor="#section2"; rel="next"
Link: <#section4>; anchor="#section3"; rel="next"
Link: <#section5>; anchor="#section4"; rel="next"

これが役に立つのかはちょっとわかりませんが、役に立つ使い方もありそうな気はします。

また、第3の資源云々というのは、後の XLink にある、始点アンカーの要素以外で定義されたリンクの仕組みを先駆けたものなのかなあという気もしますが、それを HTTP header で提供する必然性も無いですし、違うのかなあ。

[23] Link: によれば >>21 の前者はそれで問題ないようです。

[406] これ、本当に必要なのかとても疑問です。

素片識別子を使って文書の一部分と他の資源のリンクを表現するという用法はまだ理解できます。しかしそういうのは実際のレンダリングその他の処理モデルのことを考えると、マーク付け言語等々本体側の仕様と分離して定義・処理することはほとんど不可能なので、中途半端な規定と構文を HTTP ヘッダーに入れるよりは、本体側の言語に組み込んだ方が自然ですし、著者にとっても編集しやすいですし、処理もたぶんしやすいです。

他の資源からのリンクを表現するというのは、 XLink 含めハイパーテキストを Web に持ち込もうとしたシステムが何度か試みてますが、みんな失敗していて、これも成功しそうに思えない。そもそも関係ない資源のリンクを混ぜる意味なんてほとんど無いわけで。 RDF みたいな URL を濫用したシステムだって、本体に含めるので十分でヘッダーを使う必然性はないですし、他の資源からこの資源へのリンク (逆リンク) を表すというのならかろうじて理解できますが、レンダリングの方法も規定されないヘッダーに含めたところで用途が本当にあるのか疑問な上、 rev 引数とかぶってもいます。

仕様書

意味

構文

既定値

処理モデル

PROV-AQ

セキュリティー

歴史

関連

メモ