Summary

  • HTTP/1.0's 1996 Referer field let a destination learn the address of the page that led a visitor there. The RFC used it for back-links and logs, and already warned that the source of a link might be private.
  • W3C Referrer Policy later let page authors choose how much of that address travels. Under strict-origin-when-cross-origin, a secure cross-site request sends the origin rather than the full path; an HTTPS-to-HTTP request sends no referrer.

A browser reaches a new site with a little note in its pocket: here is where I came from. The HTTP/1.0 specification published as RFC 1945 in May 1996 called the note Referer, a misspelling that took on the permanence of concrete. The field could help a server build a list of back-links, inspect logs, optimize caches or find broken links. A site owner learned which pages sent visitors. The visitor may not have realized that their previous address was part of the introduction.

The 1996 text noticed the awkwardness in its own invention. A link's source could be private, it said, and users should be able to decide whether to send the field. A manually typed address had no referring page and was excluded; the fragment after # was excluded too. Yet the useful default idea remained powerful: send enough of the old page's URI for the new server to know where the click began. The same detail that makes a back-link precise can make a reading trail precise.

Consider the example later chosen by the W3C itself. A person places a link to a favorite band on a social-network profile. Someone else follows it. The band site wants to know that a visitor came from the network; it has little reason to receive the exact profile URL, which could identify the profile owner. The January 2017 W3C Referrer Policy Candidate Recommendation uses this scene to show why a web author might want a finer valve on the Referer header. A useful referral and an unnecessary address can arrive in the same envelope.

The policy vocabulary made that valve adjustable. no-referrer sends no calling card. origin sends only the scheme, host and port, leaving the path behind. strict-origin-when-cross-origin gives a page the full stripped URL for a same-origin request, sends only the origin to another secure origin, and sends nothing when a secure page points at an insecure HTTP destination. That last distinction matters: stripping a path still leaves a site's name visible, and an unencrypted trip can expose even that. Page authors could set policy through a response header or other specified mechanisms rather than plead with each outgoing link individually.

This was a change in who could make the introduction. The original HTTP header handed the browser a way to tell the destination where a link started. The later document policy let the originating page say how much of that story the browser should carry. A social site can introduce itself to a band's server without handing over a member's profile address. The receiving server still has a referral signal; the person's exact trail stays folded inside the calling card.

The June 2022 HTTP Semantics specification, RFC 9110, keeps the old spelling Referer and describes both sides of the bargain. The field still serves analytics, logging and maintenance. It can also reveal immediate browsing context or an account name in a URL. Its rules remove fragments and user information, allow truncation beyond the origin, and forbid sending a secure page's referrer into an insecure HTTP request. The old note from 1996 had become a carefully edited introduction rather than an excuse to hand over the entire address book.

The W3C publication history runs from the first public Referrer Policy draft in 2014 to the 2017 Candidate Recommendation. The dates mark documents; the mechanism is easier to see in one click. A visitor leaves a profile and reaches a band. The destination learns enough to welcome traffic from the network. It does not need the flat number and apartment behind every arrival.