Summary

  • RFC 2068 in January 1997 defined a Link entity header for relationships between resources, generally a requested resource and another one. It allowed multiple link values and used relation information like the HTML LINK element.
  • RFC 5988 in October 2010 records that the field was removed from RFC 2616 in June 1999 because there had not been enough implementation experience. The omission left the field's status unclear even as some later user agents handled it and new uses appeared.
  • RFC 5988 re-specified the header with a typed-link model independent of HTML or any one representation format. RFC 8288 in October 2017 replaced that document and retained Link as an HTTP serialization of relationships among resources.

A link rides with the response

A hyperlink printed inside an HTML page is easy to see. A reader opens the document, finds a marked phrase or a LINK element, and follows the indicated relation if its application knows what to do. But a resource is not obliged to be an HTML document. A server may send another representation, and a client may need a relationship before interpreting its body. Putting the link in the HTTP response header gives the relationship a place outside the page's format.

The January 1997 HTTP/1.1 specification, RFC 2068, offered exactly that. Its section 19.6.2.4 defined a Link entity header to describe a relation between two resources, usually the requested resource and another one. One entity could carry multiple values. Parameters included rel for the relation, title as a human-readable label and anchor for a different source anchor. The text compared the header directly with HTML's LINK element. A response could name an adjacent or previous resource without embedding that instruction in the document body.

The placement matters. HTML markup belongs to the representation a server chose to send. An HTTP field travels with the response, before a consumer parses the representation. A client that understands the field can discover the relation without requiring the content to be HTML. Yet merely carrying a Link field does not make another resource accessible, does not fetch it, and does not compel a reader application to use it. The field states a typed relationship; the application decides what that statement means for its work.

RFC 2068 placed Link among additional features. Nearby sections also described LINK and UNLINK request methods for establishing or removing relations. Those methods and the header are different protocol mechanisms. The later return of the Link header did not mean the methods also returned. Keeping them apart prevents a misleading history in which any use of the word “link” counts as the same proposal.

The 1999 edition leaves an empty space

The June 1999 revision, RFC 2616, replaced RFC 2068 without a definition of the Link header. That omission can be described more precisely than a guess about browsers. The later RFC 5988 states that Link had been removed because there was too little implementation experience. The record says the standard's authors were unwilling to make the field part of the revised base on the evidence available at the time.

That is a decision about a specification, not a census of every server or user agent. A dated set of implementations and response traces would show how many participants actually sent or understood Link in a particular year. The published reason already reveals the design tension: a plausible feature in one standards document had not yet earned a settled place in the next one.

The removal had a second effect. RFC 5988 later said the header's status became unclear, leading some designers to consider minting application-specific headers instead of reusing Link. An absent general mechanism can invite a collection of narrower names, each carrying its own rules. The question was no longer just whether a page could point somewhere else. It was whether the same typed relationship could be carried consistently when the page was not HTML, when there were several representations, or when multiple applications needed to inspect it.

The 2010 document also reported that some user agents had implemented the field after the removal, giving stylesheets as an example, while additional uses had emerged. “Some” is the document's scope. It does not make every browser, server or content type a participant. It shows why the question returned to the standardization table with more than a theoretical argument.

The link comes back without marrying HTML

RFC 5988, published in October 2010, re-specified Link with updated but backwards-compatible syntax. It also made the relationship itself a more general object. A typed link has a context resource, a relation type, a target resource and optional target attributes. The same relationship can be expressed through an HTML element, an Atom element or an HTTP header. The relation does not depend on the serialization that carries it.

That change answered a practical problem. A resource might have several representation formats. If a relation is buried only in one body's markup, a consumer of another format may not receive the same navigational information. A header can expose the relation alongside the response regardless of the body's media type. Conversely, a relation in an HTML body remains useful to an HTML reader. The specification did not set an order of authority between in-content and header links for every application; it gave them a shared model and left the application to define its behavior.

The 2010 text also broadened the link-relation registry that had grown around Atom, adding relations known from HTML. A registered relation name records what the connection means. It is not a command that a browser must automatically navigate, nor is it evidence that the target currently answers. A link might say that another resource is a stylesheet, alternate representation or license; the client still chooses which relations it understands and acts upon.

In October 2017, RFC 8288 replaced RFC 5988 and kept the central construction. It defined a link context, relation type, target and optional target attributes; Link remained one serialization in HTTP headers. Its examples distinguish a browser that looks for a stylesheet relation in HTML, optionally in an HTTP header, from an Atom application that uses other relations. A relation type describes how resources are connected, not the media type returned when a target is fetched. The format and the relationship answer different questions.

The 1997 header and the 2017 model are therefore related, but not identical documents separated by a calendar gap. The first put a relationship into an HTTP field while borrowing HTML's shape. The 2010 and 2017 documents gave such fields a broader cross-format account and explicit registration machinery. The return was a redesign around a now visible need, not simply the restoration of an old paragraph.

The standard followed a second set of footsteps

The sequence looks odd only if publication is treated as deployment. In 1997, the idea was legible enough to specify. In 1999, implementation experience was too thin to keep it in the revised base specification. In 2010, a new standards document could point to later limited implementation and use cases and define the field again. In 2017, the link model continued under a replacement RFC. Each step changed the standing of the header on paper; running programs supplied the pressure behind those changes.

There is a further stake in where the metadata lives. A relationship inside an HTML document belongs to that representation. A relationship expressed in an HTTP response can be available when the response body is not HTML. That does not make the header universally honored. It gives publishers and clients a common place to state typed connections without making every resource pretend to be a web page.

The missing deployment detail is specific: dated user-agent and server releases, or preserved HTTP response traces, would establish when named products sent and consumed the field. The RFC chain already establishes the institutional arc. Link crossed from an additional feature into omission, then returned as a cross-format standard because the need for typed relationships outlived the document that first proposed its header spelling.