RFC 6596

The Canonical Link Relation

📅 published April 2012, from ietf

Part 1 of 2 💅

Okay bestie, so this is RFC 6596 🦋. It was written by M. Ohye and J. Kupke and published in April 2012. It's Informational (so it's here to share info, not to be a binding Internet Standards Track spec ✨). It's part of the IETF stream and has ISSN 2070-1721. It doesn't obsolete or update any other RFC. It's all about defining one new link relation type, "canonical" 🔥.

Abstract

RFC 5988 explains how to describe relationships between links on the web 🌸. This doc adds a brand new relationship, "canonical", which is used to mark an Internationalized Resource Identifier (IRI) as the preferred one over resources that have duplicate content 💖.

Status of This Memo

This doc is not an Internet Standards Track specification. It's published for informational purposes 🧚.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for more on that 🫶.

If you want the latest status, any errata, or a way to send feedback, check out http://www.rfc-editor.org/info/rfc6596 ✨.

Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) as they stood on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty, as described in the Simplified BSD License 💜.

1. Introduction ✨

Okay, so the canonical link relation is how you point at the preferred IRI out of a bunch of resources with duplicative content 💅. The usual ways people use it are to name the preferred version of an IRI when duplicate pages got made by adding IRI parameters (like session IDs) 🙈. Another common one is picking the single-page version over the same content split across several component pages 🍓.

Informally, "canonical" is the author's preferred version of a resource, aka the main character of the bunch 👑. More formally, the canonical link relation names the preferred IRI from a set of resources that return the context IRI's content in duplicated form 🦋. Once it's specified, applications like search engines can focus their processing on the canonical, and references to the context (referring) IRI can be updated to point at the target (canonical) IRI 🔥.

2. Notational Conventions 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🤓.

The target (canonical) IRI MUST identify content that is either duplicative or a superset of the content at the context (referring) IRI 💖. Authors who declare the canonical link relation ought to anticipate that applications such as search engines can:

  • Index content only from the target IRI (i.e., content from the context IRIs will be likely disregarded as duplicative) 🧹.
  • Consolidate IRI properties, such as link popularity, to the target IRI 📈.
  • Display the target IRI as the representative IRI 🌟.

The target (canonical) IRI MAY:

  • Specify a relative IRI (see [RFC3986], Section 4.2) 🧭.
  • Be self-referential (context IRI identical to target IRI) 🪞.
  • Exist on a different hostname or domain 🌍.
  • Have different scheme names, such as "http" to "https" or "gopher" to "ftp" 🔐.
  • Be a superset of the content at the context IRI 🫧.
    • As an example, each component page (e.g., page-1.html, page-2.html) of a multi-page article MAY specify the "view-all" version (e.g., page-all.html), the superset of their content, as the target IRI. This is because the content from each component page is contained within the view-all version. Given this implementation, applications can mark page-1.html and page-2.html as duplicates of page-all.html, process content only from page-all.html, and disregard the component pages. All references can then be made to the view-all version (page-all.html, the target IRI), and no content will have been lost in this process. ✨
    • Using the same example above, page-2.html SHOULD NOT designate page-1.html as the target (canonical) IRI because this may cause a loss of data. When page-2.html designates page-1.html as the canonical, only content from the target IRI, page-1.html, will be processed. page-2.html may be marked as a duplicate of page-1.html and its content disregarded. 🙅‍♀️
  • Be the source IRI of a temporary redirect. For HTTP, this refers to status codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respectively, of [RFC2616]) 🔀.

To make sure applications handle the canonical link relation properly, administrators ought to consider the following guidelines 📝:

  • Specify only one canonical link relation for a resource. (It would be confusing to consider/label/designate more than one IRI as authoritative.) 🙃
  • Avoid designating the target (canonical) as:
    • The source IRI of a permanent redirect (for HTTP, this refers to 300 and 301 response codes, defined in Sections 10.3.1 and 10.3.2 of [RFC2616]) 🚫.
    • An IRI that also specifies a canonical link relation to an IRI other than itself 🔁.
    • An IRI that returns an error code, such as a 4xx response in HTTP (Section 10.4 of [RFC2616]) 💀.
    • The first page of a multi-page article or multi-page listing of items (since the first page is not duplicative or a superset of the context IRI). For example, page-2.html and page-3.html of an article SHOULD NOT specify page-1.html as the canonical. This may cause a loss of data from page-2.html and page-3.html as they will be marked duplicative of page-1.html with only content from page-1.html being processed. 😭

When the canonical link relation is declared improperly, such as creating chained canonicals (i.e., target IRI specifies the source IRI of a permanent redirect) or designating a target IRI that returns a 4xx response, applications can use their own heuristics when processing the resource. For instance, an application can choose to ignore any improper canonical designation and keep processing the remaining content on a page 🧠.

More in part 2! 🌸

Appendix A. Implementations ✨

okay so bestie, this appendix is basically the receipts 💅 It lists automated programs that actually implement stuff around the canonical link relation 🔥

Authors' Addresses 🎀

Maile Ohye 💜

EMail: maileohye@gmail.com URI: http://maileohye.com/

Joachim Kupke 🫶

EMail: joachim@kupke.za.net

📦 where this page comes from