anchor

anchor 引数 (HTTP)

[26] Link: 欄の anchor 引数は、 当該 Link: 欄で表現される Web Linking リンク始点アンカーを表します。

仕様書

意味

[28] Link: 欄で表されるリンクWeb Linking における文脈IRIは、その要求されている資源となります。しかし、これを anchor 引数によって上書きできます >>25

構文

[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 の定義上文脈IRIRFC 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 はその辺の問題には言及していません。

処理モデル

[33] 実装は anchor 引数が指定されたリンクを無視しても構いません。 その場合、 anchor 引数だけではなく、リンク全体を無視しなければなりません>>25

[34] 例えば、文脈IRIが別の資源であるようなリンクを見tめなくても構いません。 >>25

PROV-AQ

セキュリティー

[412] anchor 引数を使うと他の資源についてのリンクを記述することが可能であることから、セキュリティーについて特に配慮が必要だと指摘されています >>25 7.

歴史

[24] RFC 2068 では anchor 引数が定義されてはいたものの、 その意味は明確に説明されていませんでした。

[27] RFC 5988anchor 引数の意味を明確に規定しています。

関連

[413] HTML には anchor 引数に存在するものがありませんが、 PROV-AQ はこれを強引に表現するためにリンク型 http://www.w3.org/ns/prov#has_anchor を使っています。

メモ

[15] 2002-10-20 (日) 07:02 Link: (>>5): 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: (>>22) によれば >>21 の前者はそれで問題ないようです。

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

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

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