HTTP referer

From Wikipedia, the free encyclopedia
  (Redirected from Referrer)
Jump to: navigation, search

HTTP referer (originally a misspelling of referrer) is an HTTP header field that identifies the address of the webpage (i.e. the URI or IRI) that linked to the resource being requested. By checking the referer, the new webpage can see where the request originated.

In the most common situation this means that when a user clicks a hyperlink in a web browser, the browser sends a request to the server holding the destination webpage. The request includes the referer field, which indicates the last page the user was on (the one where they clicked the link).

Referer logging is used to allow websites and web servers to identify where people are visiting them from, for promotional or statistical purposes.[1]

Origin of the term referer[edit]

The misspelling referer originated in the original proposal by computer scientist Phillip Hallam-Baker to incorporate the field into the HTTP specification.[2] The misspelling was set in stone by the time of its incorporation into the Request for Comments standards document RFC 1945; document co-author Roy Fielding has remarked that neither "referrer" nor the misspelling "referer" were recognized by the standard Unix spell checker of the period.[3] "Referer" has since become a widely used spelling in the industry when discussing HTTP referers; usage of the misspelling is not universal, though, as the correct spelling of "referrer" is used in some web specifications such as the Document Object Model.


When visiting a webpage, the referer or referring page is the URL of the previous webpage from which a link was followed.

More generally, a referer is the URL of a previous item which led to this request. The referer for an image, for example, is generally the HTML page on which it is to be displayed. The referer field is an optional part of the HTTP request sent by the web browser to the web server.[4]

Many websites log referers as part of their attempt to track their users. Most web log analysis software can process this information. Because referer information can violate privacy, some web browsers allow the user to disable the sending of referer information.[5] Some proxy and firewall software will also filter out referer information, to avoid leaking the location of non-public websites. This can, in turn, cause problems: some web servers block parts of their website to web browsers that do not send the right referer information, in an attempt to prevent deep linking or unauthorised use of images (bandwidth theft). Some proxy software has the ability to give the top-level address of the target website as the referer, which usually prevents these problems while still not divulging the user's last-visited website.

Recently many blogs have started publishing referer information in order to link back to people who are linking to them, and hence broaden the conversation. This has led, in turn, to the rise of referer spam: the sending of fake referer information in order to popularize the spammer's website.

Many pornographic paysites use referer information to secure their websites. Only web browsers arriving from a small set of approved (login) pages are given access; this facilitates the sharing of materials among a group of cooperating paysites. Referer spoofing is often used to gain free access to these paysites.[citation needed]

It is possible to access the referer information on the client side using document.referrer in JavaScript.[6] This can be used, for example, to individualize a web page based on a user's search engine query. However, the referer field does not always include queries, such as when using Google Search with https.[7]

Referer hiding[edit]

Most web servers maintain logs of all traffic, and record the HTTP referer sent by the web browser for each request. This raises a number of privacy concerns, and as a result, a number of systems to prevent web servers being sent the real referring URL have been developed. These systems work either by blanking the referer field or by replacing it with inaccurate data. Generally, Internet-security suites blank the referer data, while web-based servers replace it with a false URL, usually their own. This raises the problem of referer spam. The technical details of both methods are fairly consistent  – software applications act as a proxy server and manipulate the HTTP request, while web-based methods load websites within frames, causing the web browser to send a referer URL of their website address. Some web browsers give their users the option to turn off referer fields in the request header.[5]

Most web browsers do not send the referer field when they are instructed to redirect using the "Refresh" field. This does not include some versions of Opera and many mobile web browsers. However, this method of redirection is discouraged by the World Wide Web Consortium (W3C).[8]

If a website is accessed from a HTTP Secure (HTTPS) connection and a link points to anywhere except another secure location, then the referer field is not sent.[9]

The upcoming standard HTML5 will support the attribute/value rel = "noreferrer" in order to instruct the user agent not to send a referer.[10]

Another referer hiding method is to convert the original link URL to a Data URI scheme-based URL containing small HTML page with a meta refresh to the original URL. When the user is redirected from the data: page, the original referer is hidden. The first public implementation of this method is the Darefer app for ownCloud.[citation needed]

Upcoming Content Security Policy standard version 1.1 introduces a new referrer directive that allows more control over the browser's behavior in regards to the Referer header. Specifically it allows the webmaster to instruct the browser to block Referer at all, reveal it only when moving with the same origin etc.[11]


  1. ^ Kyrnin, Jennifer (2012-04-10). "Referrer - What is a Referrer - How do HTTP Referrers Work?". Retrieved 2013-03-20. 
  2. ^ Hallam-Baker, Phillip (2000-09-21). "Re: Is Al Gore The Father of the Internet?". alt.folklore.computers. Retrieved 2013-03-20. 
  3. ^ Fielding, Roy (1995-03-09). "Re: Referer: (sic)". ietf-http-wg-old. Retrieved 2013-03-20. 
  4. ^ "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (RFC 7231 § 5.5.2)". IETF. June 2014. Retrieved 2014-07-26. The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained […] 
  5. ^ a b "Network.http.sendRefererHeader". MozillaZine. 2007-06-10. Retrieved 2013-03-20. 
  6. ^ "HTML DOM Document referrer Property". Retrieved 2013-03-20. 
  7. ^ Gundersen, Bret (2011-10-19). "The Impact of Google Encrypted Search". Adobe Digital Marketing Blog. Retrieved 2013-03-20. 
  8. ^ "HTML Techniques for Web Content Accessibility Guidelines 1.0: The META element". W3C. 2000-11-06. Retrieved 2013-03-20. 
  9. ^ "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content: Referer (RFC 7231 § 5.5.2)". IETF. June 2014. Retrieved 2014-07-26. A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol 
  10. ^ "4.12 Links — HTML Living Standard: Link type "noreferrer"". WHATWG. 2013-03-20. Retrieved 2013-03-20. 
  11. ^ "Content Security Policy Level 2". W3. 2014. Retrieved 2014-12-08. 

External links[edit]