Web Linking

Relation types are defined as URIs (not IRIs) to aid in their comparison and because they are not expected to be displayed to end users. Registered relation names are required to be lowercase ASCII.

http

The link model does not place restrictions on link cardinality; multiple links between the same context and target, with the same or different relation types, are permitted. Relative ordering of links is not specified or significant.

http

The 'rev' parameter (indicating reverse relationship semantics) is deprecated because it often confuses authors and readers; using a separate relation type is preferable in most cases.

http

Link targets may need to be converted to URIs for serialisations that do not support IRIs, including the Link HTTP header field. Similarly, the anchor parameter does not support IRIs.

http

Previous definitions of the Link header did not equate token and quoted-string forms explicitly; senders wishing to maximize interoperability should send 'title' as always-quoted and 'hreflang' as always-a-token.

http

When serialising HTML 'alternate'+'stylesheet' combined relation types into the Link header field, they should be serialised as a single list (rel="alternate stylesheet") to preserve their special HTML meaning.

http

Extension target attributes MAY use RFC 8187 encoding (e.g., 'example' and 'example*'). When both forms are present, they SHOULD be considered the same attribute and applications SHOULD use the '*'-suffixed value after decoding.

http

If both the title and title* link-params appear in a link, applications SHOULD use the title* link-param's value for the title attribute.

http

If the anchor parameter's value is a relative URI, parsers MUST resolve it as per RFC 3986 Section 5. Link applications MUST NOT process a link with an anchor parameter without applying the anchor.

http

If the URI-Reference in a link target is relative, parsers MUST resolve it as per RFC 3986 Section 5. Any base IRI appearing in the message's content is not applied.

http

Registered relation type names MUST conform to the reg-rel-type rule and MUST be compared character by character in a case-insensitive fashion.

http

Registered relation types MUST NOT constrain the media type of the link context and MUST NOT constrain the available representation media types of the link target.

http

Registrations for link relation types MUST reference a freely available, stable specification. The registry uses the Specification Required policy with review by a designated expert.

http, registry

Target attribute names SHOULD conform to the token rule, SHOULD NOT include '%', "'", or '*' for portability, and MUST be compared in a case-insensitive fashion.

http

The rel parameter MUST be present in each link-value but MUST NOT appear more than once; occurrences after the first MUST be ignored by parsers.

http

Using URIs to identify registered relation types by prefixing names with an application-defined base URI is NOT RECOMMENDED, because the resulting strings will not be considered equivalent to the registered relation types by other applications.

http

When extension relation types are compared, they MUST be compared as strings in a case-insensitive fashion, character by character. Clients SHOULD NOT automatically access the URI of an extension relation type to avoid overburdening its server.

http

A link is a typed connection between two resources comprising a link context, a link relation type, a link target, and optionally target attributes. It can be viewed as the statement 'link context has a link relation type resource at link target, which has target attributes.'

http

Link relation types identify the semantics of a link. There are two kinds: registered (tokens compared case-insensitively) and extension (URIs compared case-insensitively as strings).

http, registry

The serialisation-defined target attributes for the Link header field are 'hreflang' (language hint), 'media' (intended media), 'title' (human-readable label), 'title*' (RFC 8187-encoded title with language), and 'type' (media type hint). Each of 'media', 'title', 'title*', and 'type' MUST NOT appear more than once in a given link-value.

http

The 'Link Relation Application Data' registry is removed by this specification because it was unused and future use is not anticipated.

registry, http

The 'Link Relations' registry at IANA is updated by this specification. It uses Specification Required policy; the expert should be strongly biased toward approving registrations unless they are abusive, frivolous, or harmful.

registry, http

Dereferencing links exposes risks including leaking application state via the Referer header and cookies. Applications should carefully specify how such mechanisms operate to mitigate these risks.

security, http, privacy

Link header fields using the 'anchor' parameter cannot be trusted since they are assertions by a third party that could be incorrect or malicious. Applications can mitigate this by discarding such links unless a relationship between the resources is established (e.g., they share the same authority).

security, http

The content of the Link header field is not secure, private, or integrity-guaranteed. TLS with HTTP is currently the only end-to-end way to provide these properties. Applications ought to consider attack vectors from automatically following or trusting links in HTTP header fields.

security, http, tls

The Link header field ABNF is: Link = #link-value; link-value = '<' URI-Reference '>' *( OWS ';' OWS link-param ); link-param = token BWS [ '=' BWS ( token / quoted-string ) ]. Recipients MUST be able to parse both token and quoted-string forms for any link-param.

http