インターネット技術標準化委員会 (IETF) M. Nottingham
Request for Comments: 8288 2017年9月
Obsoletes: 5988
カテゴリ: 標準化トラック
ISSN: 2070-1721

Web リンク

概要

本仕様は、Web 上のリソース間の関係（「リンク」）およびその関係の種類（「リンク関係タイプ」）のモデルを定義します。

また、Link ヘッダフィールドを用いた HTTP ヘッダ内でのそのようなリンクの直列化も定義します。

このメモのステータス

これはインターネット標準化トラック文書です。

本書はインターネット技術標準化委員会（IETF）の成果物です。本書は IETF コミュニティの合意を表しており、公開のために公開レビューを受け、インターネット技術運営指導グループ（IESG）によって承認されています。インターネット標準に関する詳細は RFC 7841 のセクション2 を参照してください。

本書の現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は https://www.rfc-editor.org/info/rfc8288 で入手できます。

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

1. はじめに

本仕様は、Web 上のリソース間の関係（「リンク」）およびそれらの関係の種類（「リンク関係タイプ」）のモデルを定義します。

HTML [W3C.REC-html5-20141028] と Atom [RFC4287] はいずれもリンクの概念を明確に定義しています。Section 2 はこれらの形式や（場合によっては）他の場所でのリンクを包含する枠組みにこれを一般化します。

さらに、Section 3 はそのようなリンクを伝達するための HTTP ヘッダフィールドを定義します。

1.1. 記法上の規約

本書中のキーワード “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, および “OPTIONAL” は、BCP 14 [RFC2119] および [RFC8174] に示される通り、かつその大文字形で現れる場合に限り解釈されます。

本ドキュメントは、拡張バッカス・ノール形式（ABNF）を RFC5234 [RFC5234] の表記法で使用し、#rule を含め、明示的に次のルールを含みます: quoted-string, token, SP (space), BWS (bad whitespace), OWS (optional whitespace), RWS (required whitespace), LOALPHA, DIGIT（いずれも [RFC7230] に基づきます）。

さらに、以下のルールも含まれます：

  • URI および URI-Reference（RFC3986 から）
  • type-name および subtype-name（RFC6838 から）
  • media-query-list（W3C の Media Queries から）
  • Language-Tag（RFC5646 から）

1.2. 適合性とエラー処理

[RFC7230] の Section 2.5 で強調されている適合性およびエラー処理に関する要件は本ドキュメントにも適用されます。

4. IANA に関する考慮事項

5. セキュリティに関する考慮事項

Link ヘッダフィールドの内容は安全でもプライベートでも整合性保証されているわけではありません。これらの特性を提供するエンドツーエンドの方法としては現在、HTTP における TLS（RFC2818）の使用があります。

リンクアプリケーションは、HTTP ヘッダフィールドから収集したリンクを自動的に辿ったり信頼したり利用したりすることで開く攻撃ベクトルを考慮すべきです。

例えば、Link ヘッダフィールドが anchor パラメータを用いてリンクのコンテキストを別のリソースと関連付ける場合、これは第三者による主張に過ぎず誤りや悪意のあるものになり得ます。アプリケーションはこうしたリンクを破棄するよう指定するなど、リソース間の関係（例えば同じオーソリティを共有するかどうか）が確立されていない限り受け入れないことでリスクを緩和できます。

リンクを逆引きすることはアプリケーションに応じて多くのリスクを伴います。例えば Referer ヘッダ（RFC7231）はアプリケーションの状態（プライベート情報を含む）に関する情報をその値に露出する可能性があります。同様にクッキー（RFC6265）は別の攻撃ベクトルになり得ます。アプリケーションはこれらの仕組みの操作方法を慎重に指定することでリスクを軽減できます。

Link ヘッダフィールドは IRI と URI を広く使用します。IRI に関するセキュリティ考慮については RFC3987 Section 8 を、URI に関する考慮については RFC3986 Section 7 を、HTTP ヘッダフィールドに関する考慮については RFC7230 Section 9 を参照してください。

6. 国際化に関する考慮事項

リンクターゲットは、直列化が IRI をサポートしない場合にそれらを表現するために URI に変換される必要がある場合があります。これは Link HTTP ヘッダフィールドを含みます。

同様に、Link ヘッダフィールドの anchor パラメータは IRI をサポートしないため、含める前に IRI を URI に変換する必要があります。

関係タイプは比較を容易にするために URI として定義されています。それらがエンドユーザーに表示されることは想定されていません。

登録された Relation Name は小文字の ASCII 文字である必要があることに注意してください。

7. 参考文献

7.1. 規範的参考文献

[RFC2119]
Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC3864]
Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.
[RFC3987]
Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs)”, RFC 3987, January 2005.
[RFC5234]
Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, January 2008.
[RFC5646]
Phillips, A., Ed. and M. Davis, Ed., “Tags for Identifying Languages”, BCP 47, RFC 5646, September 2009.
[RFC6838]
Freed, N., Klensin, J., and T. Hansen, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 6838, January 2013.
[RFC7230]
Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, June 2014.
[RFC7231]
Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, June 2014.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, June 2017.
[RFC8174]
Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, May 2017.
[RFC8187]
Reschke, J., “Indicating Character Encoding and Language for HTTP Header Field Parameters”, RFC 8187, September 2017.
[W3C.REC-css3-mediaqueries-20120619]
Rivoal, F., “Media Queries”, W3C Recommendation, June 2012.

7.2. 参考情報

[RFC2046]
Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, November 1996.
[RFC2818]
Rescorla, E., “HTTP Over TLS”, RFC 2818, May 2000.
[RFC4287]
Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format”, RFC 4287, December 2005.
[RFC6265]
Barth, A., “HTTP State Management Mechanism”, RFC 6265, April 2011.
[W3C.REC-html5-20141028]
Hickson, I., et al., “HTML5”, W3C Recommendation, October 2014.

Appendix B. Link ヘッダーフィールドを解析するアルゴリズム

この付録は非規範的な一連のアルゴリズムを概説します：ヘッダセットから Link ヘッダを抽出して解析する方法、Link ヘッダフィールド値を解析する方法、およびフィールド値の一般的な部分を解析するためのアルゴリズムです。

これらのアルゴリズムは ABNF が示唆するよりも寛容であり、それに内在するエラー処理は妥当なアプローチですが必須ではありません。したがって助言的なものにすぎず、意見が分かれる場合は本仕様の本文が正しい挙動を定義します。

B.1. リンクのためのヘッダセットを解析する

このアルゴリズムは HTTP ヘッダセットに含まれる Link ヘッダフィールドを解析するために使用できます。header_set を（field_name, field_value）のペアリストと仮定すると（ASCII エンコーディング）、リンクオブジェクトのリストを返します。

  1. field_values を header_set のメンバのうち field_name が “link” と大文字小文字を区別せず一致するもののリストとする。
  2. links を空のリストとする。
  3. 各 field_value について：
    1. value_links を「リンクフィールド値を解析する」（Appendix B.2）を field_value から実行した結果とする。
    2. value_links の各メンバを links に追加する。
  4. links を返す。

B.2. リンクフィールド値を解析する

このアルゴリズムは Link ヘッダフィールドからゼロ個以上のカンマ区切りの link-value を解析します。ASCII 文字列 field_value を受け取り、リンクオブジェクトのリストを返します。

  1. links を空のリストとする。
  2. field_value に内容がある間：
    1. 先行する OWS を消費する。
    2. 最初の文字が “<” でない場合、links を返す。
    3. 先頭の文字 “<” を破棄する。
    4. 最初の “>” 文字または field_value の終端までを消費し、その結果を target_string とする。
    5. 次の文字が “>” でない場合、links を返す。
    6. 先頭の “>” を破棄する。
    7. link_parameters を「パラメータを解析する」（Appendix B.3）を field_value から実行した結果とする（ゼロ個以上の文字を消費する）。
    8. target_uri を target_string を相対解決（RFC3986 Section 5.2）した結果とする。本文の基底 URI は使用しない。
    9. relations_string を、link_parameters の最初のタプルでその最初の要素が “rel” に一致するものの第二要素、または存在しない場合は空文字列とする。
    10. relations_string を RWS で分割し、relation_types の文字列リストを得る（RWS を除去する）。
    11. context_string を、link_parameters の最初のタプルでその最初の要素が “anchor” に一致するものの第二要素とする。存在しない場合、context_string は Link ヘッダを保持する表現の URL（RFC7231 Section 3.1.4.1）を URI として直列化したものとする。URL が匿名の場合、context_string は null とする。
    12. context_uri を context_string を相対解決（RFC3986 Section 5.2）した結果とする。context_string が null の場合は context_uri は null とする。本文の基底 URI は使用しない。
    13. target_attributes を空のリストとする。
    14. link_parameters の各タプル (param_name, param_value) について：
      1. param_name が “rel” または “anchor” に一致する場合はそのタプルをスキップする。
      2. param_name が “media”, “title”, “title*” または “type” に一致し、かつ target_attributes が既に同名のタプルを含む場合、そのタプルをスキップする。
      3. (param_name, param_value) を target_attributes に追加する。
    15. star_param_names を、link_parameters のタプルのうち param_name の最後の文字が “*” であるものの param_name の集合とする。
    16. 各 star_param_name について：
      1. base_param_name を star_param_name の最後の文字を削除したものとする。
      2. 実装が base_param_name の国際化形式をサポートしない場合（仕様により禁止されている等を含むがこれに限定されない）、link_parameters から first member が star_param_name のすべてのタプルを削除し、次の star_param_name に進む。
      3. link_parameters から first member が base_param_name のすべてのタプルを削除する。
      4. link_parameters 内で first member が star_param_name のすべてのタプルの first member を base_param_name に変更する。
    17. 各 relation_type について：
      1. relation_type を小文字に正規化する。
      2. target が target_uri、relation type が relation_type、context が context_uri、target attributes が target_attributes のリンクオブジェクトを links に追加する。
  3. links を返す。

B.3. パラメータを解析する

このアルゴリズムはヘッダフィールド値からパラメータを解析します。ASCII 文字列 input を受け取り、それが含む (parameter_name, parameter_value) タプルのリストを返します。input は解析されたパラメータを削除する形で変更されます。

  1. parameters を空のリストとする。
  2. input に内容がある間：
    1. 先行する OWS を消費する。
    2. 最初の文字が “;” でない場合、parameters を返す。
    3. 先頭の “;” を破棄する。
    4. 先行する OWS を消費する。
    5. 最初の BWS, “=”, “;”, “,” のいずれかの文字または入力の終端までを消費し、その結果を parameter_name とする。
    6. 先行する BWS を消費する。
    7. 次の文字が “=” の場合：
      1. 先頭の “=” を破棄する。
      2. 先行する BWS を消費する。
      3. 次の文字が DQUOTE の場合、parameter_value を「引用文字列を解析する」（Appendix B.4）を input から実行した結果とする（ゼロ個以上の文字を消費する）。
      4. それ以外の場合、最初の “;” または “,” のいずれかの文字、または入力終端までを消費し、その結果を parameter_value とする。
      5. parameter_name の最後の文字が “*” である場合、parameter_value を RFC8187 に従ってデコードする。回復不能なエラーが発生しても処理を続行する。
    8. それ以外：
      1. parameter_value を空文字列とする。
    9. parameter_name を小文字に正規化する。
    10. (parameter_name, parameter_value) を parameters に追加する。
    11. 先行する OWS を消費する。
    12. 次の文字が “,” または入力終端であれば、処理を停止して parameters を返す。

B.4. 引用文字列を解析する

このアルゴリズムは引用文字列を RFC7230 Section 3.2.6 に従って解析します。ASCII 文字列 input を受け取り、引用解除された文字列を返します。input は解析された文字列を削除する形で変更されます。

  1. output を空文字列とする。
  2. input の最初の文字が DQUOTE でない場合、output を返す。
  3. 最初の文字を破棄する。
  4. input に内容がある間：
    1. 最初の文字がバックスラッシュ (“\”) の場合：
      1. 最初の文字を破棄する。
      2. それ以上入力がなければ output を返す。
      3. それ以外なら、最初の文字を消費して output に追加する。
    2. 最初の文字が DQUOTE の場合、それを破棄して output を返す。
    3. それ以外の場合、最初の文字を消費して output に追加する。
  5. output を返す。

Appendix C. RFC 5988 からの変更

本仕様は先行文書 RFC 5988 から次の変更を含んでいます：

  • 初期の関係タイプ登録は削除されました（既に RFC 5988 によって登録されているため）。
  • 序文が短縮されました。
  • “Link Relation Application Data” レジストリが削除されました。
  • 訂正（errata）が取り込まれました。
  • 参照が更新されました。
  • リンクの基数に関する説明が明確化されました。
  • 用語が “target IRI” / “context IRI” から “link target” / “link context” に変更されました。
  • 登録済み関係タイプへの URI 割当が直列化固有になりました。
  • Link ヘッダフィールドが HTML および Atom のリンクと意味的に同等であるという誤解を招く表現を削除しました。
  • “link serialisations” と “link applications” の用語をより慎重に定義して使用しました。
  • ターゲット属性の基数（一般的および “type” に関して）を明確化しました。
  • Link ヘッダのデフォルトのリンクコンテキストを RFC 7231 に従って表現の識別に依存するよう修正しました。
  • Link ヘッダのパースアルゴリズムを提案しました。
  • ターゲット属性の値空間と定義が指定されました。
  • ABNF が RFC7230 と互換になるよう更新され、特に空白が明示されました。
  • HTTP ヘッダ上の一部パラメータは token として現れ得るようになりました。
  • HTTP ヘッダ上のパラメータは値無しでも現れ得るようになりました。
  • 引用文字列の扱いは RFC7230 により定義されるようになりました。
  • type ヘッダパラメータは現在、（token が “/” を許さないため）引用される必要があることになりました。

著者の連絡先

Mark Nottingham
Email: mnot@mnot.net
URI: https://www.mnot.net/