[1] HTTP や 822 (電子メイル・電子ニュース)
の Link:
実体頭欄は、
実体と他の資源との関係を表現します。
[63] Web標準化の専門家には愛され長年強く推されている機能ですが、 実際にはあまり実装されておらず、それほど使われていません。
[838] Link:
欄は、 Web Linking におけるリンクを HTTP
ヘッダーとして直列化する方法です。 >>833
[839] これは HTML の link
要素や Atom
のフィードの atom:link
要素と意味的に同じ >>833
とされています。
[856] Link:
欄の構文は、まず対象URLを指定し、
その後に1つ以上の引数を指定する、というリンクを零個以上、
,
で区切って並べる形となっています。
[52] Link:
ヘッダーは様々な場面で HTTP応答のヘッダーとして使われています。
詳しくは各リンク型の項を参照してください。
[55] LDP は POST
要求のヘッダーでも
Link:
を使い、鯖での処理を指示できることとしています >>54。
[74]
RFC 8030 では、
RFC 5988 リンク関係を使うと既定されています >>73 2.1.。
RFC 5988 はリンク関係がいろいろな方法で記述できると述べ、
その1つとして Link:
HTTPヘッダーを規定しています。
RFC 8030
はどれを使うと明示しておらず、どれでもいい (なんでもいい)
とも解せますが、例示はすべて Link:
HTTPヘッダーを使っています。現実問題、
他の方法で実装されているとは思えません。
[75] 要求または応答、 URL、 リンク型について関係URLを設定するとは、 仕様書ではリンク関係型リンク型で URL を含める、というような表現がされていることを表します。 仕様書の行間を読むなら、これは次のことを表します。
[841] Link:
欄は先頭に URL を <
と >
で括って指定します。
<
と >
で括って URL を記述することを薦めてきましたが、
実際には一部の人達を除いて必ずしも普及しているとは言えません。プロトコル要素としても、
電子メールの List-*:
や RDF の N3 で使われているくらいで、
記号なし、あるいは "
で括るのが多いです。そんな中で Link:
欄の構文は異質です。[843] これは Web Linking リンクの対象IRIを表すもので、必要なら RFC 3987 が定める IRI から URI への変換を行うことにより、 RFC 3986 URI参照としたものです。 >>833
URI-Reference
の構文に従う以上のことを要求していないように思えますが (IETF では一般的な曖昧な仕様書ですねw)、
対象IRIを URI に変換したものであると説明されていること、対象IRI
が RFC 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
として定義しています。
[859] RFC 5988 の附属書によれば、 HTML や Atom の属性で >>857
に含まれていないものを link-extension
として表して良いことになっています。
[860] それ以外に link-extension
の使い方について規定はありません。
リンク関係型と違ってIANA登録簿さえありません。
[863] CoRE Link Format は Link:
欄の構文をベースに拡張した別仕様ですが、
次の引数を定義しています。これが HTTP でも使えるかについては言及されていません。
[864] 次の引数は CoRE Link Format で使うことを想定して定義されているようですが、
HTTP でも利用することを想定されているかどうかが定義上曖昧です。
[847] Web Linking リンクにおける文脈IRIは、既定ではその要求された資源ですが、
anchor
引数により上書きすることもできます。
[848] 詳しくは anchor
の項を参照してください。
[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 メッセージは配送途中で頭欄の順序が入れ替えられてしまうことが
(本来は禁止されていますが、) あります。
これは段階付けに影響しますから、
著者は同じ頭欄の複数の実現値を併合するために頭連結を使用
しても構いません。 HTML 4, 14.6
何のことかと思ってしまいますが、 HTTP
では同じ名前の頭欄が複数個使える ⇔ 値をいくつも読点で区切って指定できる
と規定されていますから、
これが 822 メッセージでも使えるという表明でしょう。
[61] 次のリンク型が指定されている場合、処理が定義されています。
WWW-Link:
ヘッダー[27] HTTP92 は HTML のメタ情報要素を HTTPヘッダーとすることが提案されているとして、
Link:
/WWW-Link:
を挙げていました。
WWW-
を付けるべきかどうかは議論があるとしていました。 >>40
[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 には拡張 (未定義) 引数の例として
type
と media
が挙げられています。
[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
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 値を持っていても構いません。メタ情報水準のリンクは典型的には階層構造や案内経路のような関係を示します。
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> 要素と同等です。
- 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つ目は資源を利用可能にした責任者が示された電子メイル・アドレスで識別されることを示します。
[3] RFC 2616 は、 RFC 2068 には書いてあるけどあまり実装されていないから説明しないよん >>17、と言っています。
[9] 引数値の引用符は、空白を含まない限り省略できます。 HTML 4, 14.6
HTML 4 のこの規定は HTTP の規定に反します。
本来引数値の引用符が省略できるのは値が token
であるときのみです。
大体、 ;
や "
が値に含まれていたら困るとわかりそうなものですが。
[11] HTTP や電子メイルの頭で認められていない文字や関門を通過できなさそうな文字を参照するために
SGML 実体
を使っても構いません。
HTML 4, 14.6
何の断りも無く SGML 実体
が使えると言われましても、
何が使えるのかわかりません。まさか任意の実体を参照できるわけではあるまいし。
おそらくは HTML 4 文字実体参照のことを指すのでしょう。
でも HTML 4 の文字実体参照はすべての文字に用意されているわけではありません。
どうせなら文字参照も認めてくれても良いのに。
もちろんそれ以前に、 HTTP のプロトコル要素の整合性という意味で、
他の頭欄では使えない SGML 実体
なるものが使えるというのは問題です。
[21] RFC 4229 は IANA登録簿に RFC 2068 を出典として登録しました >>19。 状態は「標準」とされていました >>19。
[835] RFC 5988 として2010年10月に発行されました。 RFC 5988 は Web Linking
として「書式に依存しない」リンクの概念を定義し、その一表現形式として HTTP
の Link:
欄を定義していました。
[836] RFC 5988 は、 RFC 2616 の削除の後に Link:
欄の実装が現れたこと、その一方で削除によって状態が不明確になり、本来
Link:
欄を使うべき用途で個別の独自の欄を定義して用いるケースが見られることを指摘しています。
>>837 1.
[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] CoRE は Link:
ヘッダーの構文を元に
UTF-8 化したり、引数 (対象属性) を追加したりして拡張した構文
(ヘッダーではなく本体の書式) です。
[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] 次の例は、論理的なナビゲーション経路上で前に当たる 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"
[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
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
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
Link: </v0/collection?limit=10&query=test&offset=20>; rel="next"
Link: </v0/collection?limit=10&query=test&offset=0>; rel="prev"
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.
この場合は、次のように 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
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
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
link
要素が同じ意味だとは一言も述べていません。 確かに類似していることは確かですし、歴史的に関連していることも疑いようがありませんが・・・。 (であるにも関わらず、 HTML と Atom と HTTP のリンクがすべて同じであり、 統一して規定しようとしているのが Web Linking の狙いですね・・・。)