Passa al contenuto principale

RFC 8288 - Web Linking (Collegamento Web)

  • Stato: Proposed Standard
  • Pubblicato: October 2017
  • Stream: IETF
  • Sostituisce: RFC5988
  • Errata: Nessun errata

Sommario (Abstract)​

Questa specifica definisce un modello per le relazioni tra le risorse sul Web ("collegamenti", links) e il tipo di tali relazioni ("tipi di relazione di collegamento", link relation types).

Definisce anche la serializzazione di tali collegamenti negli header HTTP con il campo header Link.

Indice (Contents)​

1. Introduction (Introduzione)​

本规范定义了Web上资源之间关系的模型("链接"，links)以及这些关系的类型("链接关系类型"，link relation types)。

HTML [W3C.REC-html5-20141028]和Atom [RFC4287]都有明确定义的链接概念；第2节将其概括为一个框架，涵盖这些格式中的链接以及(可能的)其他地方的链接。

此外，第3节定义了用于传达此类链接的HTTP头字段。

1.1. Notational Conventions (符号约定)​

本文档中的关键词"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"和"OPTIONAL"应按照BCP 14 [RFC2119] [RFC8174]中的描述进行解释，当且仅当它们以全大写形式出现时，如此处所示。

本文档使用[RFC7230]的增强巴科斯-瑙尔范式(Augmented Backus-Naur Form, ABNF) [RFC5234]符号，包括#规则，并明确包含以下规则: quoted-string, token, SP (空格), BWS (不良空白), OWS (可选空白), RWS (必需空白), LOALPHA, DIGIT。

此外，还包括以下规则:

  • URI和URI-Reference来自[RFC3986]
  • type-name和subtype-name来自[RFC6838]
  • media-query-list来自[W3C.REC-css3-mediaqueries-20120619]
  • Language-Tag来自[RFC5646]

1.2. Conformance and Error Handling (一致性和错误处理)​

[RFC7230]第2.5节中强调的关于一致性和错误处理的要求适用于本文档。

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

  • 链接上下文 (link context)
  • 链接关系类型 (link relation type) (第2.1节)
  • 链接目标 (link target)
  • 可选的目标属性 (target attributes) (第2.2节)

链接可以被视为以下形式的陈述: "链接上下文在链接目标处具有链接关系类型资源，该资源具有目标属性"。

例如，"https://www.example.com/"在"https://example.com"处具有"canonical"资源，该资源具有"text/html"的"type"。

链接上下文和链接目标都是国际化资源标识符(Internationalized Resource Identifiers, IRIs) [RFC3987]。然而，在常见情况下，链接上下文也将是URI [RFC3986]，因为许多协议(如HTTP)不支持解引用IRI。同样，链接目标有时会在不支持IRI的序列化中(例如第3节中定义的Link头字段)转换为URI(参见[RFC3987]第3.1节)。

本规范不对链接的基数施加限制；可以有多个指向特定目标和来自特定目标的链接，以及给定上下文和目标之间相同或不同类型的多个链接。同样，在任何特定序列化中或序列化之间(例如，Link头字段和内容中的链接)链接的相对顺序在本规范中未指定或不重要；希望考虑顺序重要的应用程序可以这样做。

链接在链接序列化中传达；它们是"线上的字节"，可以以各种形式出现。例如，Atom [RFC4287]和HTML [W3C.REC-html5-20141028]都定义了将链接序列化到各自格式中的方式，第3节定义了如何在HTTP头字段中序列化链接。

本规范没有定义跨不同序列化的链接的通用语法，也没有强制要求任何给定链接的特定上下文；预期链接的序列化将指定这两个方面。

最后，链接由链接应用程序使用。通常，应用程序将定义它使用的链接关系类型，以及它们可能出现的序列化。例如，应用程序"Web浏览"在HTML链接序列化中(以及可选地在Link头字段中)查找"stylesheet"链接关系类型，而应用程序"AtomPub"在Atom序列化中使用"edit"和"edit-media"链接关系。

在最简单的情况下，链接关系类型标识链接的语义。例如，具有关系类型"copyright"的链接表示当前链接上下文在链接目标处具有版权资源。

链接关系类型还可用于指示目标资源具有特定属性或表现出特定行为；例如，"service"链接意味着链接目标可以用作定义协议的一部分(在这种情况下，是服务描述)。

关系类型不应与媒体类型[RFC2046]混淆；它们不标识解引用链接时产生的表示的格式。相反，它们仅描述当前上下文如何与另一个资源相关。

关系类型不应该(SHOULD NOT)基于另一个链接关系类型的存在或不存在或其自身的出现基数来推断任何额外的语义。一个例外是"alternate"和"stylesheet"注册关系类型的组合，由于历史原因，它在HTML中具有特殊含义。

有两种关系类型: 注册的和扩展的。

2.1.1. Registered Relation Types (注册的关系类型)​

明确定义的关系类型可以注册为标记，以方便和/或促进其他应用程序的重用，使用第2.1.1.1节中的程序。

注册的关系类型名称必须(MUST)符合reg-rel-type规则(参见第3.3节)，并且必须(MUST)以不区分大小写的方式逐字符比较。它们应该(SHOULD)适合关系类型的特定性；也就是说，如果语义对特定应用程序高度特定，名称应该反映这一点，以便更通用的名称可用于不太特定的用途。

注册的关系类型禁止(MUST NOT)约束链接上下文的媒体类型，并且禁止(MUST NOT)约束链接目标的可用表示媒体类型。但是，它们可以指定目标资源的行为和属性(例如，允许的HTTP方法，以及需要支持的请求和响应媒体类型)。

2.1.2. Extension Relation Types (扩展关系类型)​

不希望注册关系类型的应用程序可以使用扩展关系类型，这是唯一标识关系类型的URI [RFC3986]。尽管URI可以指向包含关系类型语义定义的资源，但客户端不应该(SHOULD NOT)自动访问该资源以避免使其服务器负担过重。

用于扩展关系类型的URI应该(SHOULD)在定义它的人或方的控制之下或被委托给他们。

当比较扩展关系类型时，它们必须(MUST)作为字符串(如果以不同格式序列化，则在转换为URI后)以不区分大小写的方式逐字符比较。因此，应该(SHOULD)为扩展关系使用全小写URI。

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

2.2. Target Attributes (目标属性)​

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

它们可以由各个链接关系类型和链接序列化定义。

本规范不尝试协调目标属性的名称、其基数或使用。创建和维护序列化的人应该(SHOULD)协调其目标属性以避免语义或语法冲突，并可以(MAY)定义自己的目标属性注册表。

目标属性的名称应该(SHOULD)符合token规则，但SHOULD NOT被限制为ASCII；它们应该(SHOULD)以不区分大小写的方式进行比较。

Link实体头字段提供了一种在HTTP头中序列化一个或多个链接的方法。它在语义上等同于HTML的<link>元素。

Link头字段语法​

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

每个link-value传达一个链接。链接目标由尖括号（&lt; 和 >）内的URI-Reference表示。

默认情况下，链接的上下文是表示它出现的消息的有效请求URI(Effective Request URI)，如[RFC7230]第5.5节中定义的。

当存在时，上下文由Target IRI确定。请注意，任何IRI都必须根据第2节转换为URI才能在Link头字段中表示。

3.3. Relation Type (关系类型)​

链接关系类型由"rel"参数的值标识，其值必须(MUST)包含以下之一:

  • 注册的关系类型名称(参见第2.1.1节)，或
  • 扩展关系类型(参见第2.1.2节)

注册的关系类型名称和扩展关系类型可以在同一个"rel"参数值中使用，由一个或多个空格字符分隔。

relation-type  = reg-rel-type / ext-rel-type
reg-rel-type   = LOALPHA *( LOALPHA / DIGIT / "." / "-" )
ext-rel-type   = URI

请注意，扩展关系类型被编码为URI；这意味着任何保留字符都需要根据[RFC3986]第2节进行百分号编码。

3.4. Target Attributes (目标属性)​

链接的目标属性在link-value中表示为link-param。

3.4.1. Serialisation-Defined Attributes (序列化定义的属性)​

"rel"参数必须(MUST)存在，但不能(MUST NOT)出现多次；如果它不存在或出现多次，则整个link-value无效。

同样，"anchor"参数(如果存在)必须(MUST)仅出现一次；如果它出现多次，则整个link-value无效。

其他常见的目标属性包括:

  • hreflang: 指示目标资源的语言。值必须(MUST)符合[RFC5646]。
  • media: 指示目标资源的预期显示媒体。值必须(MUST)符合[W3C.REC-css3-mediaqueries-20120619]。
  • title: 用于标记目标资源的人类可读标识符。
  • title*: 使用[RFC8187]中定义的编码的国际化版本的"title"参数。
  • type: 提供关于目标资源的媒体类型的提示。

3.4.2. Extension Attributes (扩展属性)​

其他link-param值是扩展目标属性，可以由链接关系类型或链接的应用程序定义和使用。

扩展目标属性的出现或不存在不应该(SHOULD NOT)使link-value无效，但可能(MAY)影响其在特定应用程序中的使用。

例如:

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

指示"previous chapter"可以在http://example.com/TheBook/chapter2找到。

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

指示根资源("/")与自定义扩展关系类型"http://example.net/foo"相关。

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

指示标识符为"foo"的资源的版权资源可以在/terms找到。

多个链接可以在单个Link头字段中传达:

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

这里，两个链接都使用国际化的title参数。

也可以使用多个Link头字段:

Link: &lt;/TheBook/chapter2>; rel="previous"
Link: &lt;/TheBook/chapter4>; rel="next"

4. IANA Considerations (Considerazioni IANA)​

本规范更新了"Message Headers"注册表中"Link"头字段的定义。

头字段名称: Link

适用协议: http

状态: 标准

作者/变更控制者: IETF

规范文档: 本规范(第3节)

本规范建立了"Link Relation Types"注册表，位于 https://www.iana.org/assignments/link-relations/。

注册请求应包括:

  • 关系名称: 关系类型的名称
  • 描述: 类型语义的简短英文描述
  • 参考: 指定链接关系类型的文档的参考

本规范建立了"Link Relation Application Data"注册表。

Appendices (Appendici)​

HTML [W3C.REC-html5-20141028]定义了<link>元素用于传达链接。例如:

<link rel="stylesheet" href="/style.css" type="text/css">

HTML链接与本规范中定义的链接模型之间的对应关系如下:

  • 链接上下文是包含链接元素的文档的URI
  • 链接关系类型由"rel"属性的值标识
  • 链接目标由"href"属性的值标识
  • 目标属性由其他属性(如"type"、"media"等)表示

Atom [RFC4287]定义了一个链接元素，可以出现在feed和entry中。例如:

<link rel="alternate" type="text/html" 
      href="http://example.org/"/>

Atom链接与本规范中定义的链接模型之间的对应关系如下:

  • 链接上下文是包含链接元素的feed或entry的URI
  • 链接关系类型由"rel"属性的值标识
  • 链接目标由"href"属性的值标识
  • 目标属性由其他属性(如"type"、"hreflang"等)表示

本附录定义了解析Link头字段的算法。这些算法是规范性的。

给定一组HTTP头字段headers:

  1. 让links为空列表
  2. 对于headers中的每个字段field，其字段名为"Link"(不区分大小写):
    • 让field_value为field的字段值
    • 让field_links为解析field_value的结果(使用B.2节中的算法)
    • 将field_links中的每个链接添加到links
  3. 返回links

Per analizzare un valore del campo Link, elaborare il valore da sinistra a destra e produrre zero o piu link-value:

  1. Dividere il valore del campo sulle virgole che non si trovano all'interno di una stringa tra virgolette.
  2. Per ogni link-value risultante, rimuovere lo spazio bianco opzionale iniziale e finale.
  3. Il target del link DEVE essere racchiuso tra parentesi angolari. I caratteri tra < e > formano il riferimento URI di destinazione.
  4. Tutto cio che segue la parentesi angolare di chiusura > e interpretato come una lista di parametri separati da punto e virgola.
  5. Analizzare tale lista di parametri usando l'algoritmo dell'Appendice B.3.
  6. Se un nome di parametro compare piu di una volta e la definizione del parametro non consente ripetizioni, conservare la prima occorrenza e ignorare quelle successive.
  7. Restituire ogni link analizzato con il relativo riferimento URI di destinazione, il tipo di relazione e gli attributi di destinazione.

Le virgole e i punti e virgola all'interno delle stringhe tra virgolette non delimitano link-value o parametri. L'escaping con barra inversa nelle stringhe tra virgolette e gestito dall'Appendice B.4.

B.3. Parsing Parameters (解析参数)​

Per analizzare una lista di parametri:

  1. Dividere la lista sui punti e virgola che non si trovano all'interno di una stringa tra virgolette.
  2. Ignorare gli elementi vuoti prodotti da punti e virgola iniziali, finali o ripetuti.
  3. Per ogni elemento, rimuovere lo spazio bianco opzionale iniziale e finale.
  4. Il nome del parametro e il token prima del primo carattere =. Se = non e presente, il parametro ha un valore vuoto.
  5. I nomi dei parametri sono confrontati senza distinzione tra maiuscole e minuscole.
  6. Se il valore inizia con una doppia virgoletta, analizzarlo come stringa tra virgolette usando l'Appendice B.4.
  7. In caso contrario, il valore si estende fino alla fine dell'elemento dopo la rimozione dello spazio bianco opzionale.
  8. Memorizzare il nome e il valore del parametro come attributo di destinazione per il link-value corrente.

Il parametro rel identifica il tipo di relazione del link. I tipi di relazione estesi sono riferimenti URI, mentre i tipi di relazione registrati sono token.

B.4. Parsing a Quoted String (解析带引号的字符串)​

Per analizzare una stringa tra virgolette:

  1. Il valore inizia con una doppia virgoletta.
  2. Leggere i caratteri fino a trovare una doppia virgoletta non preceduta da escape.
  3. Quando si incontra una barra inversa, aggiungere il carattere successivo al valore di output e continuare.
  4. I caratteri dopo la doppia virgoletta di chiusura non fanno parte del valore quoted-string.
  5. Se manca la doppia virgoletta di chiusura, considerare il valore non valido per questo link-value.

Questo preserva le virgole, i punti e virgola e altri caratteri delimitatori tra virgolette come dati anziche come sintassi.

Appendix C. Changes from RFC 5988 (与RFC 5988的变化)​

本规范与RFC 5988相比的主要变化包括:

  • 澄清了链接上下文和链接目标的定义
  • 更新了注册程序以使用RFC 8126
  • 添加了解析算法(附录B)
  • 澄清了扩展关系类型的使用
  • 更新了对其他规范的引用
  • 改进了示例和说明文本