WWW-Link

Link: ヘッダー (HTTP)

[1] HTTP822 (電子メイル電子ニュース) の Link: 実体頭欄は、 実体と他の資源との関係を表現します。

[63] Web標準化の専門家には愛され長年強く推されている機能ですが、 実際にはあまり実装されておらず、それほど使われていません。

代替

[64] 多くの場合、 HTMLlink 要素で代用できます。

仕様書

意味

[838] Link: 欄は、 Web Linking におけるリンクHTTP ヘッダーとして直列化する方法です。 >>833

[839] これは HTMLlink 要素Atomフィードatom:link 要素と意味的に同じ >>833 とされています。

[840] しかし HTMLAtom も、それぞれの link 要素が同じ意味だとは一言も述べていません。 確かに類似していることは確かですし、歴史的に関連していることも疑いようがありませんが・・・。 (であるにも関わらず、 HTMLAtomHTTPリンクがすべて同じであり、 統一して規定しようとしているのが Web Linking の狙いですね・・・。)

構文

[856] Link: 欄の構文は、まず対象URLを指定し、 その後に1つ以上の引数を指定する、というリンクを零個以上、 , で区切って並べる形となっています。

文脈

[52] Link: ヘッダーは様々な場面で HTTP応答ヘッダーとして使われています。 詳しくは各リンク型の項を参照してください。

[55] LDPPOST 要求ヘッダーでも Link: を使い、での処理を指示できることとしています >>54

対象 URL

[841] Link: 欄は先頭に URL<> で括って指定します。

[842] このように URL を記述する構文は珍しいです。 URIRFC は歴史的に <> で括って URL を記述することを薦めてきましたが、 実際には一部の人達を除いて必ずしも普及しているとは言えません。プロトコル要素としても、 電子メールList-*:RDFN3 で使われているくらいで、 記号なし、あるいは " で括るのが多いです。そんな中で Link: 欄の構文は異質です。

[843] これは Web Linking リンク対象IRIを表すもので、必要なら RFC 3987 が定める IRI から URI への変換を行うことにより、 RFC 3986 URI参照としたものです。 >>833

[844] 一見、 RFC の規定は RFC 3986URI-Reference の構文に従う以上のことを要求していないように思えますが (IETF では一般的な曖昧な仕様書ですねw)対象IRIURI に変換したものであると説明されていること、対象IRIRFC 3987 IRI と説明されていることから、構文以外の RFC 3986/RFC 3987 の規定も適用されるものと一応解釈可能です。

[845] 相対参照である場合にあっては、 RFC 3986 に従って解決しなければなりませんメッセージ内容からの基底IRIは適用されません。 >>833

[846] というように RFC の規定は RFC 3986 に丸投げしており、 一方で RFC 3986 は一般的な説明しかしていないので、具体的にどのように解決されるべきなのか不明確ですが (IETF ではよくあること)、これは HTTP ヘッダーにおける通常の基底URL に基づき解決されると解釈されるべきです。すなわち、 Content-Location:, Content-Base:, Request-URI の順で解決されることになります。 (ただし Content-Location: は仕様上存在するだけで実際には使いものにならないとみなされており、 Content-Base: は仕様上も廃止されていますwwww)

引数

[28] Link: では次の引数が定義または利用されています。

[857] RFC 5988 では、標準の引数 (anchor, rel, rev, media, title, title*, type) の構文を定義し、それ以外の引数の構文を link-extension として定義しています。

[858] この種の RFC ではよくあることですが、 link-extension が標準の引数の構文を含んでいるので、構文の定義として実質的に意味をなさなくなっていますw

[859] RFC 5988附属書によれば、 HTMLAtom属性>>857 に含まれていないものを link-extension として表して良いことになっています。

[860] それ以外に link-extension の使い方について規定はありません。 リンク関係型と違ってIANA登録簿さえありません。

[861] RFC としては標準的な品質ですwwww

[863] CoRE Link FormatLink: 欄の構文をベースに拡張した別仕様ですが、 次の引数を定義しています。これが HTTP でも使えるかについては言及されていません。

[864] 次の引数CoRE Link Format で使うことを想定して定義されているようですが、 HTTP でも利用することを想定されているかどうかが定義上曖昧です。

文脈 URL

[847] Web Linking リンクにおける文脈IRIは、既定ではその要求された資源ですが、 anchor 引数により上書きすることもできます。

[848] 詳しくは anchor の項を参照してください。

HTTP Link: と HTML <link>

[36] Link: 欄は、 link 要素と同じ効果を持ちます。複数の Link: 欄は同じ順の link 要素と等価です。 HTML 4, 14.6

[33] HTML UA は、 Link: 欄の相対URI参照link と同じように扱うべきです。 HTML 4, 12.4.1

[29] >>33 HTML 4 の基底 URI の章のメモには釈然としないものがあります。 HTTP の頭欄の内容の解釈に HTML の base 要素が介入するというのは、ちょっと。

Link: 欄は別に HTML 専用ではなくて、 他の媒体型の実体に対しても使えるはずなのに、 どうして HTML の時だけ特別扱いなのか。。。

(実体本体を見ずに頭部だけの処理をしたい時にも問題になります。)

鯖側としては、相対 URI 参照を使わないか、 Content-Base: 欄または Content-Location: 欄を必ず併用することにすれば安全ですね。

電子メイルでの使用

[39] Link: 欄は、 HTML 文書を電子メイルで送信した時にも機能するべきです。 HTML 4, 14.6

[13] HTML 4 仕様書だから HTML 文書に限定していますが、 一般に Link: 欄に対応した MUA はどんな媒体型実体でも Link: 欄を機能させて構わないでしょう。

[8] RFC 822 メッセージは配送途中で頭欄の順序が入れ替えられてしまうことが (本来は禁止されていますが、) あります。 これは段階付け (cascade) に影響しますから、 著者同じ頭欄の複数の実現値を併合するために頭連結を使用 しても構いません。 HTML 4, 14.6

何のことかと思ってしまいますが、 HTTP では同じ名前の頭欄が複数個使える ⇔ 値をいくつも読点で区切って指定できると規定されていますから、 これが 822 メッセージでも使えるという表明でしょう。

処理

[61] 次のリンク型が指定されている場合、処理が定義されています。

詳細は各項を参照。

歴史

WWW-Link: ヘッダー

[27] HTTP92HTMLメタ情報要素HTTPヘッダーとすることが提案されているとして、 Link:/WWW-Link: を挙げていました。 WWW- を付けるべきかどうかは議論があるとしていました。 >>40

[43] RFC 4229HTTP92 を出典として使っていますが、なぜか WWW-Link:IANA登録簿に登録していません。

[42] >>32, >>41 でも WWW-Link: に言及されていました。

I-D

[18] 昔の HTTP の仕様書では Link: 欄には href 属性もあって、 リンク先 URI はこちらに指定したんだそうです。

[26] HTTP and HTML Metadata Linking Mechanism I-D 1997-05, <urn:ietf:id:draft-daviel-metadata-link-00><http://www.watersprings.org/pub/id/draft-daviel-metadata-link-00.txt>

[22] An Entity Header for Linked Resources <http://www.w3.org/Protocols/9707-link-header.html>: I-D の draft。 最終修正1999年4月。

[24] >>22 には拡張 (未定義) 引数の例として typemedia が挙げられています。

[25] WebDAV は最終仕様ではリンクXML の要素で表現してますが、 当初は HTTP の Link: 欄を使う予定だったようで、 仕様の検討が行われています。

Thread index of w3c-dist-auth@w3.org mailing list <http://lists.w3.org/Archives/Public/w3c-dist-auth/threads.html#01482>

[48] Links for Web Authoring (1996-12-09 12:09:32 +09:00 版) <http://www.w3.org/Authoring/WD-authlink.html>

[7] RFC 1945 (HTTP/1.0) D.2.6 Link

The Link entity-header field provides a means for describing a relationship between the entity and some other resource. An entity may include multiple Link values. Links at the metainformation level typically indicate relationships like hierarchical structure and navigation paths.

[2] Link 実体頭欄は実体と何か他の資源との間の関係を記述する手段を提供するものです。実体は複数の Link 値を持っていても構いません。メタ情報水準のリンクは典型的には階層構造や案内経路のような関係を示します。

[12] RFC 2068 (HTTP/1.1) 19.6.2.4 Link

The Link entity-header field provides a means for describing a relationship between two resources, generally between the requested resource and some other resource. An entity MAY include multiple Link values. Links at the metainformation level typically indicate relationships like hierarchical structure and navigation paths. The Link field is semantically equivalent to the <LINK> element in HTML.[5]

[4] Link 実体頭欄は実体と何か他の資源との間の関係を記述する手段を提供するものです。実体は複数の Link 値を持っていても構いません。メタ情報水準のリンクは典型的には階層構造や案内経路のような関係を示します。 Link 欄は意味的には HTML の <LINK> 要素と同等です。

[10]

  • Link = "Link" ":" #("<" URI ">" *( ";" link-param )
  •           link-param     = ( ( "rel" "=" relationship )
                                 | ( "rev" "=" relationship )
                                 | ( "title" "=" quoted-string )
                                 | ( "anchor" "=" <"> URI <"> )
                                 | ( link-extension ) )
  • link-extension = token [ "=" ( token | quoted-string ) ]
  • relationship = sgml-name | ( <"> sgml-name *( SP sgml-name) <"> )
  • sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )

注意: RFC 2068 の URI とは、 URI参照 (URI と素片識別子の一方または両方) のことです。

Relationship values are case-insensitive and MAY be extended within the constraints of the sgml-name syntax. The title parameter MAY be used to label the destination of a link such that it can be used as identification within a human-readable menu. The anchor parameter MAY be used to indicate a source anchor other than the entire current resource, such as a fragment of this resource or a third resource.

[5] 関係値は大文字・小文字を区別せず、 sgml-name 構文に従う範囲で拡張しても構いません。 title パラメーターは link 対象に札付けするのに使って構いません。これは人可読メニュー中で識別するのに使用出来ます。 anchor パラメーターは、現在の資源全体でない、 当該資源の断片や第3の資源を始点アンカーとして示すのに使用しても構いません

Examples of usage include:

The first example indicates that chapter2 is previous to this resource in a logical navigation path. The second indicates that the person responsible for making the resource available is identified by the given e-mail address.

[6] 最初の例は第2章が論理案内経路中でこの資源の前であることを示します。 2つ目は資源を利用可能にした責任者が示された電子メイル・アドレスで識別されることを示します。

RFC 2616 (HTTP/1.1)

[3] RFC 2616 は、 RFC 2068 には書いてあるけどあまり実装されていないから説明しないよん >>17、と言っています。

HTML4

[9] 引数値の引用符は、空白を含まない限り省略できます。 HTML 4, 14.6

HTML 4 のこの規定は HTTP の規定に反します。 本来引数値の引用符が省略できるのは値が token であるときのみです。

大体、 ;" が値に含まれていたら困るとわかりそうなものですが。

[11] HTTP や電子メイルの頭で認められていない文字や関門を通過できなさそうな文字を参照するために SGML 実体を使っても構いません。 HTML 4, 14.6

何の断りも無く SGML 実体が使えると言われましても、 何が使えるのかわかりません。まさか任意の実体を参照できるわけではあるまいし。 おそらくは HTML 4 文字実体参照のことを指すのでしょう。 でも HTML 4 の文字実体参照はすべての文字に用意されているわけではありません。 どうせなら文字参照も認めてくれても良いのに。

もちろんそれ以前に、 HTTP のプロトコル要素の整合性という意味で、 他の頭欄では使えない SGML 実体なるものが使えるというのは問題です。

RFC 4229

[21] RFC 4229IANA登録簿RFC 2068 を出典として登録しました >>19。 状態は「標準」とされていました >>19

独立 RFC へ

[835] RFC 5988 として2010年10月に発行されました。 RFC 5988Web Linking として「書式に依存しない」リンクの概念を定義し、その一表現形式として HTTPLink: 欄を定義していました。

[836] RFC 5988 は、 RFC 2616 の削除の後に Link: 欄の実装が現れたこと、その一方で削除によって状態が不明確になり、本来 Link: 欄を使うべき用途で個別の独自の欄を定義して用いるケースが見られることを指摘しています。 >>837 1.

[855] RFC 5988IANA登録簿における Link: 欄の出典となっています >>837 6.1.

[862] 初期は URL雛形を使った Link-Template: 欄も提案されていました。 >>46, >>15, >>16

関連

[31] HTML 4 仕様書は、 Link 頭を定義する版の HTTP では と前置きして Link 欄を説明しています。 RFC 1945 や RFC 2068 の実装なら使えて RFC 2616 の実装では使えないような言い方ですが、 HTTP の版と頭欄の使用の可否は関係がありません。 RFC 2616 の実装が Link を使うことに何ら問題はありません。

(版が問題となるのは、非互換な変更が導入された時だけです。 詳しくは RFC 2145 を読んでください。)

[44] HTTP 頭欄により暗示される link 要素や meta 要素は、 head 要素で明示されているものより前に出現したと定義します。 HTML 4, 14.6

ところで、 Link: 欄の説明で唐突に meta 要素型が登場するわけでありますが、一体何を意味しているのでしょう?

[51] CoRELink: ヘッダーの構文を元に UTF-8 化したり、引数 (対象属性) を追加したりして拡張した構文 (ヘッダーではなく本体の書式) です。

CoRE を参照。
[53] UTF-8 化されているにも関わらず、 引数RFC 5987 拡張構文 (title*) もなぜか含まれています。 互換性のため、あるいは言語タグの指定のためなのでしょうか。

実装

[20] LWP (というか HTML::HeadParser) は HTML 中に link 要素があると、 href 属性は所定の形式に変換して、残りの属性は全て (; 区切りに直した上で) そのまま引数としてつけていきます。

[34] HTTP Link: 欄の例 HTML 4, 14.6、改

Link: <http://www.acme.example/corporate.css>; REL=stylesheet

[35] >>34 を HTML 4 で書いた例 HTML 4, 14.6、改

<LINK rel="stylesheet" href="http://www.acme.example/corporate.css">

[38] 複数のスタイル・シートを指定する例 HTML 4, 14.6、改

Link: <compact.css>; rel="stylesheet"; title="compact"
Link: <bigprint.css>; rel="alternate stylesheet"; title="big print"

この例では、 compact.css優先スタイルで、 bigprint.css代替スタイルです。

[824] W3C mobileOK Scheme 1.0 ( 版) <http://www.w3.org/TR/2009/NOTE-mobileOK-20090625/#linkingClaims>

Link: <powder.xml>; rel="describedby" type="text/powder+xml";

構文的におかしいですw

[851] 次の例は、論理的なナビゲーション経路 (logical navigation path) 上で前に当たる URL を表しています。 >>833

Link: <http://example.com/TheBook/chapter2>; rel="previous";
      title="previous chapter"

[852] 次の例 >>833 は、拡張関係型 http://example.net/fooリンクです。 相対URLは当該資源要求URLに対して解決されて解釈されます。

Link: </>; rel="http://example.net/foo"

[853] 次の例は RFC 2231 符号化により title* 引数を使って UTF-8 文字列を言語情報付きで記述しています >>833。また , による連結で、2つのリンクを1つのヘッダーで表しています。

Link: </TheBook/chapter2>;
      rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
      </TheBook/chapter4>;
      rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

[854] 次の例 >>833 は2つのリンク型の2つのリンクを1つのヘッダーで表しています。

Link: <http://example.org/>;
      rel="start http://example.net/relation/other"
1つのリンクに2つのリンク型が指定されているのではなく、2つのリンクがあると解釈されます。

メモ

[37] Link: 欄は、 複数の文書群にまとめて同じスタイル・シートを指定したいようなときに特に有用です。 HTML 4, 14.6

[14] 2002-10-20 (日) 07:00 >>10-11: 使わないといけないのか否かはっきりしないと、 & なんてのはよく使いそうな文字ですから、問題になります。

[45] Googleの調査によれば、Link: 欄もいくらかは使われているらしいです。

(名無しさん [sage] 2006-02-07 03:41:51 +00:00)

 
[47]
Re: http-link-header in GRDDL (Harry Halpin 著, 2007-02-11 12:53:51 +09:00 版) <http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/0153.html>
(名無しさん 2007-02-18 09:29:00 +00:00)

[49] LinkHeader - ESW Wiki (2007-09-29 19:05:27 +09:00 版) <http://esw.w3.org/topic/LinkHeader> (名無しさん)

[50] Content Transformation Guidelines 1.0 ( 版) <http://www.w3.org/TR/2008/WD-ct-guidelines-20080801/#d2e1267>

[823] draft-roach-sip-http-subscribe-00 - A SIP Event Package for Subscribing to Changes to an HTTP Resource ( 版) <http://tools.ietf.org/html/draft-roach-sip-http-subscribe-00>

[826] IRC logs: freenode / #whatwg / 20091010 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20091010>

[827] IRC logs: freenode / #whatwg / 20091013 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20091013#l-225>

[828] IRC logs: freenode / #whatwg / 20100807 ( 版) <http://krijnhoetmer.nl/irc-logs/whatwg/20100807#l-270>

[829] IRC logs: freenode / #whatwg / 20101210 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20101210>

[830] Bug 102907 – Link toolbar doesn't support HTTP links headers ( ( 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=102907>

[831] An Entity Header for Linked Resources ( ( 版)) <http://www.w3.org/Protocols/9707-link-header.html>

[832] Web Applications 1.0 r5798 Remove the text that was trying to handwave the Link: header's non-existence, now that it exists formally again. ( ( 版)) <http://html5.org/tools/web-apps-tracker?from=5797&to=5798>

[834] PROV-AQ: Provenance Access and Query ( ( 版)) <http://www.w3.org/TR/2012/WD-prov-aq-20120110/#resource-accessed-by-http>

[849] IRC logs: freenode / #whatwg / 20120424 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20120424#l-458>

[850] 587928 – Disable support for <meta http-equiv="Link"> ( ( 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=587928>

[865] Events | GitHub API ( ( 版)) <http://developer.github.com/v3/events/>

[866] 748294 – remove support for Link HTTP header ( ( 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=748294>

[867] Link prefetching FAQ | MDN ( ( 版)) <https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ>

[868] Re: Behavior of <meta> elements linking in stylesheets ( (Ian Hickson 著, 版)) <http://lists.w3.org/Archives/Public/www-style/2004Apr/0072.html>

[869] IRC logs: freenode / #whatwg / 20130823 ( ( 版)) <http://krijnhoetmer.nl/irc-logs/whatwg/20130823#l-709>

[870] 3248 – HTTP headers are not passed on to main NGLayout code [IMPORT] ( ( 版)) <https://bugzilla.mozilla.org/show_bug.cgi?id=3248>

[871] Linked Data Platform 1.0 ( ( 版)) <http://www.w3.org/TR/2014/WD-ldp-20140311/#h5_ldpr-gen-linktypehdr>

[872] Buzzword.org.uk Draft: jsonGRDDL ( ( 版)) <http://buzzword.org.uk/2008/jsonGRDDL/spec#sec_syntax_headers>

[873] Issue 58456 - chromium - Link HTTP header - An open-source project to help move the web forward. - Google Project Hosting ( ( 版)) <https://code.google.com/p/chromium/issues/detail?id=58456>

[874] Index of /tests/evil/acid/004 ( ( 版)) <http://hixie.ch/tests/evil/acid/004/>

[875] ORE User Guide - Resource Map Discovery ( ( 版)) <http://www.openarchives.org/ore/1.0/discovery#HTTPLinkHeader>

[876] RFC Errata Report ( ( 版)) <http://www.rfc-editor.org/errata_search.php?rfc=4229>

[877] Collections - Mendeley Developer Portal ( ( 版)) <http://dev.mendeley.com/reference/topics/pagination.html>

[878] GoCardless API Docs ( ( 版)) <https://developer.gocardless.com/#pagination>

[54] Linked Data Platform 1.0 ( 版) <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#h-ldpc-post-createrdf>

Clients use the same syntax, that is HTTP Link headers, to specify the desired interaction model when creating a resource as servers use to advertise it on responses.

[56] 言語や地域の URL に hreflang を使用する - Search Console ヘルプ ( 版) <https://support.google.com/webmasters/answer/189077>

[57] 498117 – LINK HTTP headers don't work for linking to feeds ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=498117>

[58] Model for Tabular Data and Metadata on the Web ( 版) <http://www.w3.org/TR/2015/REC-tabular-data-model-20151217/#h-link-header>

processors must retrieve the metadata file referenced by any Link header with:

rel="describedby", and

type="application/csvm+json", type="application/ld+json" or type="application/json".

[59] Is RFC5988 supported by implementers? · Issue #424 · w3c/manifest ( 版) <https://github.com/w3c/manifest/issues/424>

[60] Orchestrate (Orchestrate 著, 版) <https://orchestrate.io/docs/apiref#bulk>

Link: </v0/collection?limit=10&query=test&offset=20>; rel="next"

Link: </v0/collection?limit=10&query=test&offset=0>; rel="prev"

[65] Webmention () <https://webmention.net/draft/#h-sender-discovers-receiver-webmention-endpoint>

If more than one of these is present, the first HTTP Link header takes precedence, followed by the first <link> or <a> element in document order.

[66] 正規 URL を使用する - Search Console ヘルプ ( ()) <https://support.google.com/webmasters/answer/139066?hl=ja>

この場合は、次のように rel="canonical" HTTP ヘッダーを使用すると、この PDF ファイルの正規 URL を Google に示すことができます。

Link: <http://www.example.com/downloads/white-paper.pdf>; rel="canonical"

現在 Google では、これらのリンクヘッダー要素をウェブ検索でのみサポートしています。

[67] Bug 20018 – Linking to style sheets with HTTP headers is not implemented in WebKit () <https://bugs.webkit.org/show_bug.cgi?id=20018>

[68] Linked Data Notifications () <https://linkedresearch.org/ldn/#test-consumer-header-discovery>

Senders and consumers should omit the Link header discovery when specifically targeting URIs with fragment identifiers.

[69] Clarify that Link header processing only happens after the Document i… (yoavweiss著, ) <https://github.com/w3c/preload/commit/609ecfa8cdb9cc582a11f87eff290e69e76b3346>

[70] Clarify - Link header processing only happens after Document is created by yoavweiss · Pull Request #110 · w3c/preload () <https://github.com/w3c/preload/pull/110>

[71] How do we fetch resources specified in `Link` headers? · Issue #101 · w3c/preload () <https://github.com/w3c/preload/issues/101>

[72] Activities – Flow API Reference () <https://developer.getflow.com/api/#activities_get-activities>

The response will have an HTTP status of 200 OK and have a Link header with the URL to fetch for the next page of results.

Link: next=https://api.getflow.com/activities?organization_id=52&read_after=2016-06-14T20:37:39Z&read_before=2016-06-15T20:37:39Z