互联网工程任务组 (IETF)

M. Nottingham

请求评论：8288

2017年9月

废止：5988

类别：标准轨道

ISSN: 2070-1721

Web 链接

摘要

本规范定义了 Web 上资源之间关系（“链接”）的模型，以及这些关系的类型（“链接关系类型”）。

它还定义了在 HTTP 首部中使用 Link 首部字段对这些链接进行序列化的方式。

本备忘录状态

这是一个互联网标准轨道文档。

本文件是互联网工程任务组（IETF）的成果，代表 IETF 社区的共识。它已接受公开审查并由互联网工程指导小组（IESG）批准发布。有关互联网标准的更多信息，请参阅 RFC 7841 第2节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息，可在 https://www.rfc-editor.org/info/rfc8288 获取。

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. 引言
- 1.1. 符号约定
- 1.2. 合规性与错误处理
2. 链接
- 2.1. 链接关系类型
  - 2.1.1. 已注册的关系类型
  - 2.1.2. 扩展关系类型
- 2.2. 目标属性
3. 在 HTTP 首部中序列化链接
- 3.1. 链接目标
- 3.2. 链接上下文
- 3.3. 关系类型
- 3.4. 目标属性
  - 3.4.1. 由序列化定义的属性
  - 3.4.2. 扩展属性
- 3.5. Link 首部字段示例
4. IANA 注意事项
5. 安全性注意事项
6. 国际化注意事项
7. 参考文献
- 7.1. 规范性参考文献
- 7.2. 补充性参考文献
Appendix A. 关于其他链接序列化的说明
- A.1. HTML 中的链接序列化
- A.2. Atom 中的链接序列化
Appendix B. 解析 Link 首部字段的算法
Appendix C. 相对于 RFC 5988 的更改
作者地址

1. 引言

本规范定义了 Web 上资源之间关系（“链接”）的模型以及这些关系的类型（“链接关系类型”）。

HTML [W3C.REC-html5-20141028] 与 Atom [RFC4287] 都有定义良好的链接概念；第 2 节将其泛化为一个框架，涵盖这些格式中的链接以及（可能的）其它场景。

此外，第 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]）以及 [RFC7230] 中的 #rule，并显式包含其定义的以下规则：quoted-string、token、SP（空格）、BWS（bad whitespace）、OWS（optional whitespace）、RWS（required whitespace）、LOALPHA、DIGIT。

此外，还包含以下规则：

来自 [RFC3986] 的 URI 与 URI-Reference，
来自 [RFC6838] 的 type-name 与 subtype-name，
来自 [W3C.REC-css3-mediaqueries-20120619] 的 media-query-list，
以及来自 [RFC5646] 的 Language-Tag。

1.2. 合规性与错误处理

与合规性与错误处理相关的要求参见 [RFC7230] 第 2.5 节，这些要求也适用于本文档。

2. 链接

在本规范中，链接是两个资源之间的带类型的连接，由下列部分组成：

链接上下文，
一个链接关系类型（第 2.1 节），
链接目标，和
可选的目标属性（第 2.2 节）。

链接可以被视为形式为：“链接上下文对应链接关系类型资源于链接目标，且具有目标属性”的陈述。

例如，“https://www.example.com/” 在 “https://example.com” 有一个 “canonical” 资源，该资源的 “type” 为 “text/html”。

链接上下文与链接目标都是国际化资源标识符（IRI）（参见 [RFC3987]）。然而在常见情形中，链接上下文通常也是一个 URI（参见 [RFC3986]），因为许多协议（如 HTTP）不支持对 IRI 的解析。同样地，在不支持 IRI 的序列化（例如第 3 节中定义的 Link 首部字段）中，链接目标有时会被转换为 URI（参见 [RFC3987] 第 3.1 节）。

本规范对链接的基数不作限制；特定上下文可以有多个指向或来自特定目标的链接，并且在给定的上下文与目标之间可以存在相同或不同类型的多个链接。同样，任何特定序列化中或跨序列化之间（例如 Link 首部字段与内容内链接）链接的相对顺序在本规范中既未规定也不重要；希望考虑顺序的应用可以自行处理。

链接通过链接序列化进行传递；它们是“在线上的字节”，并可以以多种形式出现。例如，Atom [RFC4287] 与 HTML [W3C.REC-html5-20141028] 都定义了将链接序列化到它们各自格式中的方法，第 3 节定义了如何在 HTTP 首部字段中序列化链接。

本规范不定义跨不同序列化的一般链接语法，也不规定任何特定链接的上下文；期望链接的序列化会指定这两个方面。

最后，链接被链接应用（link applications）使用。通常，一个应用会定义其使用的链接关系类型以及它们可能出现的序列化。例如，“Web 浏览”应用在 HTML 链接序列化（以及可选地在 Link 首部字段）中查找 “stylesheet” 链接关系类型，而“AtomPub”应用在 Atom 序列化中使用 “edit” 与 “edit-media” 链接关系。

2.1. 链接关系类型

在最简单的情形下，链接关系类型标识了链接的语义。例如，关系类型为 “copyright” 的链接表示当前链接上下文在链接目标处有一个版权资源。

链接关系类型也可用于指示目标资源具有特定属性或表现出特定行为；例如，“service” 链接意味着链接目标可以作为定义协议（例如服务描述）的一部分被使用。

关系类型不应与媒体类型（参见 [RFC2046]）混淆；它们不标识在解析链接后得到的表示的格式。它们仅描述当前上下文与另一个资源之间的关系。

关系类型不应基于另一个关系类型的存在或不存在、或其出现次数来推断附加语义。一个例外是 “alternate” 与 “stylesheet” 这两个已注册的关系类型在 HTML 中的组合，出于历史原因具有特殊含义。

关系类型分为两类：已注册（registered）与扩展（extension）。

2.1.1. 已注册的关系类型

定义明确的关系类型可以作为 token 注册，以便于重用或促进其它应用的复用，注册程序见第 2.1.1.1 节。

已注册的关系类型名称必须符合 reg-rel-type 规则（参见第 3.3 节）并以不区分大小写的方式逐字符比较。名称应与关系类型语义的专属性相匹配；即如果语义强烈依赖特定应用，则名称应反映该特性，以便通用名称可供较不具体的用途使用。

已注册的关系类型不得限制链接上下文的媒体类型，也不得限制链接目标可用的表示媒体类型。然而，它们可以指定目标资源的行为与属性（例如，允许的 HTTP 方法，以及必须支持的请求与响应媒体类型）。

历史上，已注册的关系类型用在名称前加上应用定义的基础 URI（例如参见附录 A.2）来以 URI 标识。这种做法 不被推荐，因为由此得到的字符串不会被其它应用视为与已注册关系类型等价。若应用在内部使用此类 URI，则在不显式支持的序列化中不得在链接序列化中使用它们。

2.1.1.1. 注册链接关系类型

“Link Relations” 注册表位于 “https://www.iana.org/assignments/link-relations/”。可以按照该处的说明提交注册请求，或发送邮件到 “link-relations@ietf.org” 邮件列表。

注册请求至少应包含以下信息：

Relation Name：关系类型的名称
Description：对该类型语义的简短英文描述。应以链接上下文与链接目标之间的关系来陈述。
Reference：指定该链接关系类型的文档引用，最好包含可检索该文档的 URI。也可包含相关章节指示，但非必需。

专家可定义注册表中应收集的其他字段。

已注册关系类型的一般要求见第 2.1.1 节。

注册必须参考一个可自由获取且稳定的规范。

注意，若未注册的关系类型已被广泛部署且专家判断其不太可能及时注册，第三方（包括专家）也可以注册该关系类型。此类注册仍须满足规定的要求，包括需要引用规范。

2.1.1.2. 注册请求的处理

关系类型使用 Specification Required 策略进行注册（参见 [RFC8126] 第 4.6 节），这意味着需要由指定专家审查与批准。

注册表的目标是反映互联网中链接的常见用法。因此，专家应偏向于批准注册，除非注册请求具有滥用性、无价值、不太可能在互联网上使用，或对互联网/万维网有害（不仅仅是审美上不合或架构上可疑）。如第 2.1.1 节所述，专家可拒绝注册那些对提议应用过于宽泛的名称。

若注册被拒绝，专家会明确指出导致拒绝的问题。可以就提议的链接关系类型的语义提供建议，但若不构成注册阻碍，应明确说明。

当请求被批准时，专家将通知 IANA 并处理注册。IESG 是解决任何异议的最终仲裁者。

2.1.2. 扩展关系类型

不希望注册关系类型的应用可以使用扩展关系类型，它是一个 URI（参见 [RFC3986]），用于唯一标识该关系类型。尽管该 URI 可以指向包含关系类型语义定义的资源，但客户端不应自动访问该资源以避免对其服务器造成负担。

用于扩展关系类型的 URI 应由定义者本人控制或已委托给其控制。

比较扩展关系类型时，必须在转换为 URI 后以逐字符、不区分大小写的字符串比较方式进行。鉴于此，建议对扩展关系使用全小写的 URI。

注意，尽管扩展关系类型要求是 URI，但链接的序列化可以指定它们以另一种形式表示，只要可以将其转换为 URI 即可。

2.2. 目标属性

目标属性是描述链接或其目标的一组键/值对；例如，媒体类型提示。

它们可以由单个链接关系类型定义，也可以由链接序列化定义。

本规范不尝试协调目标属性的命名、基数或使用方式。创建与维护序列化的人员应当协调它们的目标属性以避免语义或语法冲突，并且可以定义自己的目标属性注册表。

目标属性名称应当符合 token 规则，但不应包含字符 “%”、“'” 或 “*”，以便在不同序列化间便携，并且必须以不区分大小写的方式比较。

目标属性定义应当指定：

将其值序列化为 Unicode 或其子集，以最大化在不同链接序列化间的可移植性；
针对给定链接上目标属性多次出现时的语义与错误处理规定。

本规范在第 3.4 节为 Link HTTP 首部字段定义了可用的目标属性。

3. 在 HTTP 首部中序列化链接

Link 首部字段提供了一种将一个或多个链接序列化到 HTTP 首部的方法。

该字段值的 ABNF 如下：

  Link       = #link-value
  link-value = "<" URI-Reference ">" *( OWS ";" OWS link-param )
  link-param = token BWS [ "=" BWS ( token / quoted-string ) ]

注意，任何 link-param 都可以用 token 或 quoted-string 语法生成值；因此，接收者必须能够解析这两种形式。换言之，以下参数是等价的：

  x=y
  x="y"

先前对 Link 首部的定义并未明确地将 token 与 quoted-string 形式等价地对待；title 参数总是被引用，而 hreflang 参数总是作为 token。希望最大化互操作性的发送方将按这些传统形式发送它们。

各个 link-param 在其必要的去引号（unquoting）之后指定它们的语法（参见 [RFC7230] 第 3.2.6 节）。

本规范建立了通用链接模型的一些 link-params：“rel”、“anchor” 与 “rev”，以及序列化定义的目标属性：“hreflang”、“media”、“title”、“title*” 与 “type”。

3.1. 链接目标

每个 link-value 在尖括号（“<>”）中传递一个目标 IRI 作为 URI-Reference（如有必要先转换为 URI-Reference；参见 [RFC3987] 第 3.1 节）。如果 URI-Reference 是相对的，解析器必须按照 [RFC3986] 第 5 节解析它。注意消息内容中出现的任何 base IRI 不会被应用。

3.2. 链接上下文

默认情况下，Link 首部字段中传达的链接的上下文是与其关联的表示的 URL，按照 [RFC7231] 第 3.1.4.1 节的定义，并以 URI 形式序列化。

当 anchor 参数存在时，它会以另一个 URI 覆盖该默认上下文，例如文档片段、或第三个资源（即当 anchor 值为绝对 URI 时）。如果 anchor 参数的值是相对 URI，解析器必须按照 [RFC3986] 第 5 节解析它。注意正文内容中的任何 base URI 不会被应用。

anchor 参数值的 ABNF 如下：

  URI-Reference ; Section 4.1 of [RFC3986]

链接应用可选择忽略带有 anchor 参数的链接。例如，所使用的应用可能不允许将链接上下文指定为另一个资源。在这种情况下，应忽略整个链接；链接应用不得在不应用 anchor 的情况下处理该链接。

注意，根据 HTTP 状态码与响应首部，链接上下文可能是“匿名”的（即没有可用的链接上下文）。例如，对 GET 请求的 404 响应就是这种情况。

3.3. 关系类型

在 Link 首部字段中传达的链接的关系类型通过 rel 参数的值传达。rel 参数必须出现，但在给定 link-value 中不得出现多次；在出现多次的情况下，解析器应忽略第一次之后的出现。

rel 参数可以包含多个链接关系类型。当发生这种情况时，它会建立多个具有相同上下文、目标与目标属性的链接。

过去曾使用 rev 参数表示关系语义为反向。即，从 A 到 B 的 REL=”X” 与从 B 到 A 的 REV=”X” 表示相同关系。本规范弃用 rev，因为它常常让作者与读者混淆；在大多数情况下，更倾向于使用单独的关系类型。

rel 与 rev 参数值的 ABNF 如下：

  relation-type *( 1*SP relation-type )

其中：

  relation-type  = reg-rel-type / ext-rel-type
  reg-rel-type   = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
  ext-rel-type   = URI ; Section 3 of [RFC3986]

注意，扩展关系类型在 Link 首部字段中要求为绝对 URI，并且当它们包含 token 中不允许的字符（例如分号 “;” 或逗号 “,”，这些字符在首部字段中用作定界符）时必须被引用。

3.4. 目标属性

Link 首部字段为该序列化定义了若干目标属性，并允许扩展目标属性。目标属性在 Link 首部字段中作为参数序列化（参见 [RFC7231] 第 3.1.1.1 节关于它们语法的定义）。

3.4.1. 由序列化定义的属性

“hreflang”、“media”、“title”、“title*” 与 “type” 这些 link-params 可被映射为该序列化的目标属性。

当存在时，“hreflang” 属性是一个提示，表明解析链接后得到的资源的语言应为何种语言。注意这仅是一个提示；例如，它不会覆盖实际跟随链接获得的 HTTP 响应的 Content-Language 首部字段。在单个 link-value 上出现多个 hreflang 属性表示从所指资源可用多种语言。

hreflang 参数值的 ABNF 如下：

  Language-Tag

当存在时，“media” 属性用于指示样式信息的目标媒介或媒体（参见 [W3C.REC-html5-20141028] 第 4.2.4 节）。如果它包含分号 “;” 或逗号 “,”，其值必须被引用。link-value 中不得出现多个 media 属性；出现的后续项应被解析器忽略。

media 参数值的 ABNF 如下：

  media-query-list

当存在时，“title” 属性用于标注链接的目标，使其可作为面向人类的标识（例如菜单项），语言由 Content-Language 首部字段（若存在）指示。title 属性不得在同一链接中出现多次；出现的后续项应被解析器忽略。

“title*” link-param 可用于按 [RFC8187] 的方式在不同字符集下编码该属性并/或包含语言信息。title* link-param 不得在同一 link-value 中出现多次；出现的后续项应被解析器忽略。如果属性不包含语言信息，则其语言由 Content-Language 首部字段（存在时）指示。

如果在同一链接中同时出现 title 与 title*，应用应当使用 title* 的值作为 title 属性。

当存在时，“type” 属性是一个提示，表明解析链接后得到的资源的媒体类型应为何种类型。注意这仅是一个提示；例如，它不会覆盖实际跟随链接获得的 HTTP 响应的 Content-Type 首部字段。type 属性不得在同一 link-value 中出现多次；出现的后续项应被解析器忽略。

type 参数值的 ABNF 如下：

  type-name "/" subtype-name ; see Section 4.2 of [RFC6838]

3.4.2. 扩展属性

其它 link-params 属于链接扩展（link-extensions），并被视为目标属性。

此类目标属性可以定义为使用 [RFC8187] 中的编码（例如 “example” 与 “example*”）。当两种形式同时存在时，应当将它们视为同一目标属性；应用应当使用以“*”结尾的名称的值（在按 [RFC8187] 解码后），但在解码出错或不支持解码时可以回退到另一个值。

3.5. Link 首部字段示例

例如：

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

表示 “chapter2” 在逻辑导航路径上位于该资源之前。

类似地，

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

表示根资源（“/”）与该资源具有扩展关系类型 “http://example.net/foo”。

下列链接：

Link: </terms>; rel="copyright"; anchor="#foo"

表示所链接的版权条款仅适用于文档中由媒体类型相关的片段标识符 “foo” 指示的部分。

下面的示例展示了 Link 首部字段对多个链接的编码实例，以及使用 RFC 8187 的编码来编码非 ASCII 字符与语言信息：

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

这里，两个链接的标题都使用 UTF-8 编码，语言均为德语（“de”），第二个链接包含了 Unicode 码点 U+00E4（“LATIN SMALL LETTER A WITH DIAERESIS”）。

注意 link-value 可以在相同的链接目标与链接上下文之间传达多个链接；例如：

Link: <http://example.org/>;
      rel="start http://example.net/relation/other"

在此，指向 “http://example.org/” 的链接同时具有已注册的关系类型 “start” 与扩展关系类型 “http://example.net/relation/other”。

最后，该首部字段：

Link: <https://example.org/>; rel="start",
      <https://example.org/index>; rel="index"

等价于：

Link: <https://example.org/>; rel="start"
Link: <https://example.org/index>; rel="index"

4. IANA 注意事项

4.1. Link HTTP 首部字段注册

本规范更新了 HTTP 中 “Link” 的 “Message Headers” 注册表条目（参见 [RFC3864]），以引用本文档。

Header Field Name: Link
Protocol: http
Status: standard
Reference: RFC 8288

4.2. 链接关系类型注册表

本规范更新了 “Link Relation Types” 注册表的注册程序；见第 2.1.1.1 节。此外，注册表中所有对 RFC 5988 的引用已被替换为对本文档的引用。

IANA 将把任何进入注册表的请求转到本文档以及（如果有）专家建立的流程；通常这意味着将它们引用到注册表的网页。

注意专家（如第 2.1.1.1 节所述）被允许定义注册表中应收集的额外字段。

4.3. 链接关系应用数据注册表

依据本规范，IANA 已移除 “Link Relation Application Data” 注册表，因为其未被使用且预计不会在未来使用。

5. 安全性注意事项

Link 首部字段的内容不提供机密性、隐私或完整性保证。使用带有 HTTP 的传输层安全（TLS）（参见 [RFC2818]）是目前提供这些端到端属性的唯一方式。

链接应用应当考虑自动跟随、信任或以其它方式使用从 HTTP 首部字段收集到的链接所打开的攻击向量。

例如，使用 “anchor” 参数将链接的上下文与另一个资源关联的 Link 首部字段不能被信任，因为它们实际上是第三方的断言，可能是错误的或恶意的。应用可以通过指定仅在资源之间建立某种关系（例如共享相同的 authority）时才保留此类链接来缓解该风险，否则应丢弃这些链接。

解析链接存在多种风险，取决于所使用的应用。例如，Referer 首部（参见 [RFC7231]）可能在其值中暴露有关应用状态（包括私人信息）。同样，cookie（参见 [RFC6265]）也是一种机制，若被使用，可能成为攻击向量。应用可以通过谨慎地指定这些机制的工作方式来缓解这些风险。

Link 首部字段广泛使用 IRI 与 URI。有关 IRI 的安全注意事项，请参见 [RFC3987] 第 8 节。有关 URI 的安全注意事项，请参见 [RFC3986] 第 7 节。有关 HTTP 首部字段的安全注意事项，请参见 [RFC7230] 第 9 节。

6. 国际化注意事项

为了在不支持 IRI 的序列化中表达链接目标，链接目标可能需要被转换为 URI。这包括 Link HTTP 首部字段。

类似地，Link 首部字段的 anchor 参数不支持 IRI；因此在包含之前必须将 IRI 转换为 URI。

为了便于比较，关系类型被定义为 URI 而非 IRI。预计它们不会被直接展示给终端用户。

注意已注册的关系名称要求为小写 ASCII 字母。

7. 参考文献

7.1. 规范性参考文献

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

7.2. 补充性参考文献

[RFC2046]: Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types”, RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2818]: Rescorla, E., “HTTP Over TLS”, RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC4287]: Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format”, RFC 4287, DOI 10.17487/RFC4287, December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC6265]: Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.
[W3C.REC-html5-20141028]: Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Navara, E., O'Connor, T., and S. Pfeiffer, “HTML5”, World Wide Web Consortium Recommendation REC-html5-20141028, October 2014, <http://www.w3.org/TR/2014/REC-html5-20141028>.

Appendix A. 关于其他链接序列化的说明

首部字段（第 3 节）只是链接的一种序列化；其它规范已定义替代的序列化方式。

A.1. HTML 中的链接序列化

HTML 激发了最初的 Link 首部字段语法，本文档中的许多设计决策都出于与其兼容性的考虑。

在 HTML 中，link 元素可通过使用 “href” 属性表示目标 URI、使用 “rel” 传达关系类型来映射为本文所述的链接，就像在 Link 首部字段中一样。链接的上下文是与整个 HTML 文档关联的 URI。HTML 还定义了若干可视为目标属性的链接属性，包括 “media”、“hreflang”、“type” 与 “sizes”。

HTML5 的第 4.8 节（参见 [W3C.REC-html5-20141028]）定义了现代 HTML 链接。该文档链接到 Microformats Wiki 作为一个注册表；随着时间推移，IANA 注册表应当反映其内容并（理想情况下）最终取代它（尽管这取决于 HTML 社区）。

对现有 HTML 内容的调查显示，未注册且非 URI 的链接关系类型（也许不可避免地）是常见的。消费 HTML 的实现不应将此类未注册的短链接视为错误，而应将其视为具有局部作用域的关系类型（即其含义是特定且可能对该文档私有的）。

最后，当 “alternate” 关系类型与同一链接中的其它关系类型同时出现时，HTML 规范赋予其特殊含义。为了保留此关系，这类链接在 Link 首部字段中应当使用单一的关系类型列表进行序列化（例如 rel=”alternate stylesheet”）。

A.2. Atom 中的链接序列化

Atom（参见 [RFC4287]）是一种链接序列化，它在 atom:link 元素中传达链接，使用 “href” 属性指示链接目标，使用 “rel” 属性包含关系类型。链接的上下文取决于出现位置，可能是 feed 的定位符或 entry 的 ID；通常，feed 级别的链接是可作为 Link 首部字段传输的明显候选。

将 atom:link 序列化为 Link 首部字段时，有必要将链接目标（如被使用）转换为 URI。

Atom 将扩展关系类型定义为 IRI。本规范将它们重新定义为 URI，以简化比较并减少错误。

Atom 允许使用前缀 “http://www.iana.org/assignments/relation/” 将已注册的链接关系类型序列化为绝对 URI。该前缀是 Atom 序列化特有的。

此外，链接关系类型在比较时总是区分大小写；因此，将已注册的链接关系类型序列化到 Atom 文档时，应当将其转换为注册形式（通常为小写）。

还要注意，虽然 Link 首部字段允许在单个 link-value 中序列化多个关系，但 atom:link 不允许。在这种情况下，单个 link-value 可能映射为若干 atom:link 元素。

与 HTML 类似，atom:link 定义了一些未在 Link 首部字段语法中明确映射的属性，但它们可以作为链接扩展使用以保持信息一致性。

Appendix B. 解析 Link 首部字段的算法

本附录概述了一组非规范性的算法：用于从首部集合中解析 Link 首部、解析 Link 首部字段值，以及解析字段值通用部分的算法。

这些算法比 ABNF 所定义的语法更为宽松；其中体现的错误处理是一种合理的方法，但并非强制性要求。因此这些算法仅供建议，在出现分歧的情况下，正确行为由本规范主体定义。

B.1. 解析包含链接的首部集合

该算法可用于解析 HTTP 首部集合中包含的 Link 首部字段。给定一个由（字符串 field_name, 字符串 field_value）对组成的 header_set，假定为 ASCII 编码，它返回一个链接对象列表。

令 field_values 为 header_set 中其 field_name 与 “link” 不区分大小写匹配的成员列表。
令 links 为一个空列表。
对于 field_values 中的每个 field_value：
1. 令 value_links 为从 field_value 中执行 “解析 Link 字段值”（见附录 B.2）的结果。
2. 将 value_links 的每个成员附加到 links。
返回 links。

B.2. 解析 Link 字段值

该算法从 Link 首部字段解析零个或多个以逗号分隔的 link-values。给定一个字符串 field_value，假定为 ASCII 编码，它返回一个链接对象列表。

令 links 为空列表。
当 field_value 有内容时：
1. 消费任何前导 OWS。
2. 如果第一个字符不是 “<”，则返回 links。
3. 丢弃第一个字符（“<”）。
4. 消费直到但不包括第一个 “>” 字符或 field_value 结束，并令结果为 target_string。
5. 如果下一个字符不是 “>”，则返回 links。
6. 丢弃前导的 “>” 字符。
7. 令 link_parameters 为从 field_value 中解析参数（附录 B.3）的结果（消费其中零个或多个字符）。
8. 令 target_uri 为对 target_string 进行相对解析（按 [RFC3986] 第 5.2 节）的结果。注意正文中携带的任何 base URI 不会被使用。
9. 令 relations_string 为 link_parameters 中第一个元组的第二项，该元组的第一项匹配字符串 “rel”；如果不存在则 relations_string 为空字符串（""）。
10. 按 RWS 拆分 relations_string（并在过程中移除），得到 relation_types 字符串列表。
11. 令 context_string 为 link_parameters 中第一个元组的第二项，该元组的第一项匹配字符串 “anchor”。若不存在，则 context_string 为承载 Link 首部的表示的 URL（按 [RFC7231] 第 3.1.4.1 节），以 URI 形式序列化；若该 URL 为匿名，则 context_string 为 null。
12. 令 context_uri 为对 context_string 进行相对解析（按 [RFC3986] 第 5.2 节）的结果，除非 context_string 为 null，在此情况下 context 为 null。注意正文中携带的任何 base 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 中已包含第一个元素匹配 param_name 的元组，则跳过该元组。
  3. 将 (param_name, param_value) 附加到 target_attributes。
15. 令 star_param_names 为 link_parameters 中那些 param_name 最后字符为星号（“*”）的参数名集合。
16. 对于 star_param_names 中的每个 star_param_name：
  1. 令 base_param_name 为去掉最后一个字符后的 star_param_name。
  2. 如果实现选择不支持名为 base_param_name 的参数的国际化形式（包括但不限于其被该参数规范禁止），则从 link_parameters 中移除所有第一成员为 star_param_name 的元组，然后继续下一个 star_param_name。
  3. 从 link_parameters 中移除所有第一成员为 base_param_name 的元组。
  4. 将 link_parameters 中所有第一成员为 star_param_name 的元组的第一成员改为 base_param_name。
17. 对于 relation_types 中的每个 relation_type：
  1. 将 relation_type 规范化为小写。
  2. 将一个链接对象附加到 links，包含目标 target_uri、关系类型 relation_type、上下文 context_uri 以及目标属性 target_attributes。
返回 links。

B.3. 解析参数

该算法从首部字段值解析参数。给定输入 input（ASCII 字符串），它返回其中包含的一组 (字符串 parameter_name, 字符串 parameter_value) 元组列表。input 会被修改以移除已解析的参数。

令 parameters 为空列表。
当 input 有内容时：
1. 消费任何前导 OWS。
2. 如果第一个字符不是 “;”，则返回 parameters。
3. 丢弃前导的 “;” 字符。
4. 消费任何前导 OWS。
5. 消费直到但不包括第一个 BWS、“=”、“;”、“,” 字符或输入结束，并令结果为 parameter_name。
6. 消费任何前导 BWS。
7. 如果下一个字符是 “=”：
  1. 丢弃前导的 “=” 字符。
  2. 消费任何前导 BWS。
  3. 如果下一个字符是 DQUOTE，则令 parameter_value 为从 input 中解析引用字符串（附录 B.4）的结果（消费其中零个或多个字符）。
  4. 否则，消费直到但不包括第一个 “;” 或 “,” 字符，或直到输入结束，并令结果为 parameter_value。
  5. 如果 parameter_name 的最后字符为星号（“*”），则按 [RFC8187] 对 parameter_value 解码。在遇到不可恢复错误时继续处理输入。
8. 否则：
  1. 令 parameter_value 为空字符串。
9. 将 parameter_name 规范化为小写。
10. 将 (parameter_name, parameter_value) 附加到 parameters。
11. 消费任何前导 OWS。
12. 如果下一个字符是 “,” 或输入结束，停止处理输入并返回 parameters。

B.4. 解析引用字符串

该算法解析引用字符串（按 [RFC7230] 第 3.2.6 节）。给定输入 input（ASCII 字符串），它返回一个去引号后的字符串。input 会被修改以移除已解析的字符串。

令 output 为空字符串。
如果 input 的第一个字符不是 DQUOTE，则返回 output。
丢弃第一个字符。
当 input 有内容时：
1. 如果第一个字符是反斜杠（“\”）：
  1. 丢弃第一个字符。
  2. 如果没有更多输入，返回 output。
  3. 否则，消费第一个字符并将其附加到 output。
2. 否则，如果第一个字符是 DQUOTE，则丢弃它并返回 output。
3. 否则，消费第一个字符并将其附加到 output。
返回 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/