Http Referer Not Always Being Passed

HTTP Referer not always being passed

If a user visits your site directly, there is no referrer. It's also possible they have set it up so their browser never sends the referrer.

According to this answer, browsers do not necessarily send a referrer when doing a meta refresh.

In what cases will HTTP_REFERER be empty

It will/may be empty when the enduser

• entered the site URL in browser address bar itself.
• visited the site by a browser-maintained bookmark.
• visited the site as first page in the window/tab.
• clicked a link in an external application.
• switched from a https URL to a http URL.
• switched from a https URL to a different https URL.
• has security software installed (antivirus/firewall/etc) which strips the referrer from all requests.
• is behind a proxy which strips the referrer from all requests.
• visited the site programmatically (like, curl) without setting the referrer header (searchbots!).

In what cases HTTP referer will be truncated

HTTP referrer headers are created by browsers according to desired criteria using Referrer Policy even though there is a general standard used by majority of the browsers there are some differences about how the browsers handles the servers instructions, mainly mobile web browsers are the ones which does not cooperate nicely with WWWC recommendations on this matter.

So why is there need for different HTTP referrer headers? To understand this we need to look at what are these headers are used for first. Main purpose in its simplest form is "carrying information from the originating page to the new page".

Everywhere we see the word "information" in the web there is a information security concept attached to it and HTTP header is no different. Depending on what kind of information headers carry, server can specify the type of referrer policy needs to be used. Here is the list of referrer policies from W3

enum ReferrerPolicy {
"",
"no-referrer",
"no-referrer-when-downgrade",
"same-origin",
"origin",
"strict-origin",
"origin-when-cross-origin",
"strict-origin-when-cross-origin",
"unsafe-url"
};

Detailed information about each of these are available in the Referrer policy link i included above.

To give an example;
Using google searching for "Yellow Pages". in this case

origin:https://www.google.ie

referer:https://www.google.ie/

Referrer Policy:origin

generated URL:https://www.google.ie/gen_204?atyp=i&ct=&cad=udla=3&ei=x65kGDkdyKGHDkF0KeoBg&e=12&zx=1494785478502

link to the first result is

https://www.google.ie/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiA26TfiHSGDFHKFAKHQXoCWUQFggoMBB&url=https%3A%2F%2Fwww.goldenpages.ie%2F&usg=AFQjCNGTG-tsBSFHgMkXw_GuvOcLEOD2hg

While the actual URL is https://www.goldenpages.ie/

When we actually click the link referrer changes to

Referer:https://www.goldenpages.ie/ and the referrer policy is

Referrer Policy:no-referrer-when-downgrade

This means if we click another link from the current page we won't see all the additional parameters similar to the ones we saw in the URL from google search results page.

To prove this is the case; click any link from the current page and watch the referrer header changing according to the the policy type (Which can be found in the associated js file if you use developer tools and inspect the network activity)

When i click the "List your business" link referrer stay as

https://www.goldenpages.ie/list-your-business/

and no other parameters are passed

So just to tidy up this messy explanation; What URL gets generated is dependent on what rules are set regarding to Referrer policy may that be a simple base rule with no parameters or a very long URL with loads of information relating to the user and origin of the navigation.

Note: URLs wont work i have jumbled some letters.

Result from $_SERVER['HTTP_REFERER'], when referer header is not sent to server

If the HTTP referer request header is not sent then the $_SERVER['HTTP_REFERER'] is probably not set, although it could be an empty string. Whether it is set or not in this case could depend on the server.

As with all HTTP request headers, check for its existence when reading:

$httpReferer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : null;

What are there circumstances in which no referer header will be passed for an https - https link?

The text quoted in the question was in fact an error, and has now been changed. So the answer to this question is:

Such circumstances would be outside the specification. No such circumstances are currently known.

$_SERVER['HTTP_REFERER'] missing

From the documentation:

The address of the page (if any) which referred the user agent to the
current page. This is set by the user agent. Not all user agents will
set this, and some provide the ability to modify HTTP_REFERER as a
feature. In short, it cannot really be trusted.

http://php.net/manual/en/reserved.variables.server.php

Why isn't the the Referer header removed for Google HTTPS - HTTP?

cnst answers this correctly above; it's content="origin". That forces browsers going HTTPS->HTTPS and HTTPS->HTTP to have the request header:

http-referer=https://www.google.com  

This functionality allows sites to get credit for traffic without leaking URL parameters to a third party. It's awesome, as it's so much less hacky than what people have used here in the past.

There are currently three competing specs for this. I don't know which one is authoritative, and suspect it's a mix. They're similar, on most points.

• http://www.w3.org/TR/referrer-policy/
• http://w3c.github.io/webappsec/specs/referrer-policy/
• https://wiki.whatwg.org/wiki/Meta_referrer

Here's available support, that I know of; would love for people to let me know if I'm wrong or missing anything.

Now:

• Chrome 17+ supports this on desktop
• Chrome 25+ for mobile devices
• Safari 6 on iPad and iPhone

Unknown version:

• Desktop Safari 7 supports this; possible support in earlier versions, but I don't have a browser to confirm.

Upcoming real soon now:

• IE12 Beta has working support (new this week).
• Firefox 38 has the code checked in for a May 2015 release. https://bugzilla.mozilla.org/show_bug.cgi?id=704320

---

Related Topics