Summary

  • RFC 1945, published in May 1996, described Referer as a request header that could tell a destination server the URI of the page where its link appeared. Backlink lists, logs and repairs were the stated uses. The same section warned that a source address could reveal a private document.
  • RFC 2068, published in January 1997, retained the mechanism, called the header's spelling an error, and described the privacy risk in its security section. A typed address had no referring page to report; a fragment was excluded from the header value.
  • A W3C Candidate Recommendation dated 26 January 2017 described Referrer-Policy choices including a full URL, an origin without the page path, and no referrer at all. It is a dated policy specification, not a count of browser deployments.

The receiving server wanted a return address

The HTTP/1.0 specification published as RFC 1945 in May 1996 gave the receiving server an optional clue about a visitor's route. A browser following a link could send a Referer request header containing the URI of the page from which the target URI had been obtained. The server on the other side could then make a list of pages pointing to its document, keep a log, improve caching, or find an obsolete or mistyped link that needed repair. The specification named these uses plainly. A source address looked like practical maintenance information.

Imagine a research library moving a page while old links still point to its former location. A request that carries the previous page's address can tell the library which outside site has a stale citation. The receiving operator may never have seen that site before. Referer made the web's many independent links visible from the destination. It was a poor man's reverse index, written into the journey of each eligible request rather than maintained by a central directory.

The header had limits from the start. The 1996 text said it must not be sent when the target address came from a source without its own URI, such as a user typing into the browser. It also ruled out the fragment from the URI in the header. A click from a page and a typed address were different events. The destination could learn a page of origin from the former, but could not conjure a referring document from the latter.

That same section placed the cost of the clue beside its benefit. The source of a link might itself be private, or its address might reveal a private information source. The authors strongly recommended a user choice over whether the field was sent, even offering the idea of a browser switch between open and anonymous browsing. The warning was present in the 1996 design record. Privacy did not arrive as a later objection from somebody who had failed to appreciate backlinks.

A typo that kept its job

The HTTP/1.1 specification published as RFC 2068 in January 1997 kept the field and acknowledged its name with a little editorial wince: Referer was the misspelled form of “referrer.” The header on the wire remained Referer. The receiving server still gained a back-link list, logs and a way to trace bad links. The document again forbade the field when the source had no URI and excluded fragments from the value.

The spelling became a visible artifact of the web's early running code. A neat correction on paper would not change the name that clients and servers had learned to exchange. Yet the typo is the least important part of the paragraph. The more consequential choice was to put information about the departing page into a request to the arriving server. That destination had a legitimate maintenance interest. It did not automatically have a claim to know every path by which a reader reached it.

RFC 2068's security discussion made the clash explicit. A server could study reading patterns and draw reverse links from Referer. Even after personal details were separated from data, the field could still disclose the URI of a private document. Consider a page whose address includes a profile path, a case reference or a token. Sending the page address to a different site tells that site something about the page the reader just left. The risk lies in the address itself, not merely in a name pasted next to it.

The original documents do not establish that every browser sent every possible source URL. They define a header, describe its use and set constraints. What they do establish is a built-in tension: a destination server wanted enough origin information to fix its map of the web; the source page and its reader might have a reason to keep that origin narrower. Both purposes were written into the standard before the web had a mature vocabulary for deciding between them.

The address was more than a site name

A full source URL can reveal far more than the domain that hosted it. A path may identify a particular profile or private workspace. A query string may contain a session identifier or another value that grants access. The destination can learn this context simply by receiving a request generated from the source page. The information did not travel in the visible text of the link. It rode alongside the request as metadata.

This made the direction of control awkward. The destination could log the value; the source page was the place whose context might leak. A reader might click because the destination content was useful, not because they intended to tell that destination exactly where they had been. The 1996 RFC's proposed user switch was one answer. It put the choice in the browser user's hands. But a site author also knew something the recipient could not: whether a page address had sensitive structure and whether a bare site name would give the recipient enough useful attribution.

The distinction between a full page and a site origin matters. A destination might need to know that traffic came from a research library but have no need for the individual reader's profile URL within it. An origin-only return address preserves a broad path of discovery while withholding the particular document path. Silence withholds the route entirely. Those are different operational answers, not two names for the same privacy setting.

The page author gets a policy dial

The W3C Referrer Policy Candidate Recommendation of 26 January 2017 put those choices into a more detailed design. Its opening example is concrete: a social site's profile page links to a band's website. The band site might reasonably be told that a visit came from the social site, while the profile's full URL could identify a user. The document also gives the case of a URL carrying a session identifier or a capability. The address itself can be a credential-like object.

The draft specified policies with distinct disclosure levels. no-referrer omits the header. same-origin sends the source URL within the same origin but sends none across origins. origin sends only the scheme, host and port of the source, discarding the page path and query. strict-origin adds a rule against sending that origin when moving from a protected context to an untrustworthy destination. Other options combine different behavior for same-origin and cross-origin requests. One could allow the full URL in more cases; another could strip it for external destinations.

Control could be delivered through a Referrer-Policy response header, a document meta element, an element attribute or a noreferrer link relation. The policy name was spelled correctly, while the outgoing HTTP request field it governed stayed Referer. The split is a small historical joke: the newer instruction fixed the English, but it did not rewrite the older message name.

The 2017 text was a Candidate Recommendation, a dated W3C specification. It describes what a conforming implementation would do under each policy. It does not provide a census of browsers using those controls. A dated implementation record would establish when each browser shipped the choices. The standards record is enough to show the shift in the design question: instead of only asking whether a browser should send a return address, the source page could express how specific that address ought to be.

A backlink is also a disclosure

The receiving server's wish to know where a link came from never disappeared from this story. It is useful to repair broken citations and to understand which pages lead readers to a resource. The 1996 RFC was not foolish to name those jobs. Its own privacy warning recognized the price. When the source URI is a private page, the same bit of bookkeeping can turn into an unwanted disclosure to a different operator.

The later policy dial let that price be negotiated at the source, where the page's context was known. A site could send its origin and keep its profile paths private, or send nothing across sites. The recipient would lose some detail in its backlink ledger. That loss is the actual trade: the party maintaining the destination no longer gets to treat the reader's departure address as a free receipt for every click.

The field's misspelling survived. More importantly, the web developed a way to separate “which site sent this visit?” from “which exact page did the reader leave?” That distinction is the point at which a useful reverse link stopped being a default claim over somebody else's private path.

Sources