How can I pass referrer header from my https domain to http domains?

Question

My website is 100% https. I have links to other http domains. The referrer header is not set when linking from a https page to a http page. From http://en.wikipedia.org/wiki/HTTP_referrer

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.

I would prefer that other domains can see the referrer so that they know that traffic comes from my domain. Is there a way to force this header or is there another solution?

Update

I've done some basic testing using a redirect:

http page  -- link to http  --> 301 redirect --> http page = referrer intact
https page -- link to https --> 301 redirect --> http page = referrer blank
https page -- link to http  --> 301 redirect --> http page = referrer blank
https page -- link to http  --> 302 redirect --> http page = referrer blank

The referrer is lost when linking from a https page to a http redirect page on my own domain. So there is no referrer on the redirect.

Solution 1

I was able to set up a link from an HTTPS page to a HTTP page on another domain and still pass the first page's URL as a referrer using the following technique.

Definitions

Origin page: HTTPS page where the link to the HTTP hosted destination page is situated. In this example: https://example1.com/origin.html

Destination page: HTTP page which has access to the referrer of the origin page. In this example: http://example2.com/destination.html

Basic plan

This has the effect of making the redirect come from the HTTP version of the origin page:

1. Link on HTTPS origin page links to the current page but adds a query parameter for the destination page[1]. e.g: https://example1.com/origin.html?goto=http://example2.com/destination.html

2. When link is clicked the server at example1.com interrupts the standard request when the query parameter 'goto' is present. It then:

   • Stores the 'goto' parameter in a 'goto' cookie.
   • Removes the 'goto' parameter and value from the current request's url
   • 302 redirects to this new cleaned url on the HTTP version of the origin domain ie. http://example1.com/origin.html

3. The server checks on every request for a 'goto' cookie and if present will clear the cookie and then render a very simple redirect page. This page contains[2]:

   • A Javascript window.location.replace() script that redirects to the goto cookie url.
   • A Meta Refresh tag with the value of the goto cookie url and a delay of a few seconds.
   • A link to the goto cookie url.

Notes

[1] This basic solution is an open redirector and some consideration should be given to protecting against bad guys using the goto query parameter to redirect UAs in phishing attacks.

[2] Not all browsers will send the referrer when redirecting via a JS redirect or meta refresh tag. In my testing IE8 and lower does not pass the referrer.

I'm not sure if this technique will allow search engine crawlers to follow the links. This is not important for my requirements.

If the UA has cookies disabled then this will just redirect to the origin page again.

Allowing HTTP connections just for redirects

On my server I have an Apache rule for enforcing HTTPS regardless of the request:

<VirtualHost *:80>
    ServerName example1.com

    # if not on port 443 then 301 redirect to https while keeping any query string
    RewriteEngine              On
    RewriteCond %{HTTP_HOST}  ^example1\.com$ [NC]
    RewriteCond     %{SERVER_PORT} !443
    RewriteRule     ^(.*)$     https://%{HTTP_HOST}$1 [L,QSA,R=301]

In order for the redirection technique above to work I need some way to conditionally permit HTTP connections. There are many ways to do this. I decided a cookie will work.

<VirtualHost *:80>
    ServerName example1.com

    # if not on port 443 then 301 redirect to https while keeping any query string
    RewriteEngine              On
    RewriteCond %{HTTP_HOST}  ^example1\.com$ [NC]
    RewriteCond     %{SERVER_PORT} !443
    RewriteCond %{HTTP_COOKIE}  !disable_ssl [NC]
    RewriteRule     ^(.*)$     https://%{HTTP_HOST}$1 [L,QSA,R=301]

The disable_ssl cookie would be set in step 2 and then deleted in step 3.

Solution 2

As mentioned is this answer there is a new method of doing this: Referrer Policy/meta tag.

See spec and example in this q&a.

Solution 3

I also had this same problem. I solve by adding meta tag like below and it will be work only in Chrome and Safari.

<meta name="Referrer" content="origin">

Solution 4

Sadly you can not referrer on HTTPS to sites using HTTP. You can however do HTTPS to HTTPS or HTTP to HTTPS.

SOURCE

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

A work around would be to use a internal redirect script that rather than directing linking out to the visitor on the HTTPS you redirect to HTTP and then it redirects out.

For example:

<a href="http://www.yours.com/out.php?www.other.com">www.outboundsite.com</a> but this wouldn't use the original referrer.

Another possibility is using trackbacks rather than referrers and as far as I know this works in HTTPS.

Solution 5

according to HTTP 1.1 protocol http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure

View more solutions

Comments

[nutcracker]

My testing has indicated that using a redirect doesn't work (see update).

[Simon Hayter]

Use trackbacks or lose the HTTPS ;)

[nutcracker]

Good idea! I had thought about this workaround but wondered if their was some "rules" around implementing this from my end. Normally these query parameters are added by the third-party website so they can track their campaigns etc. Would this approach be considered bad practice in any way?

[Martijn]

Why shouldn't I?

[Pacerier]

Ok.... but this doesn't exactly pass the "referrer header".

[Pacerier]

@bybe, This answer needs an edit. See serverfault.com/a/520603/87017 and webmasters.stackexchange.com/a/71331/7654