Is it possible, that Letsencrypt prevents $_SERVER['HTTP_REFERER'] to pass the referring domain?

Question

When I execute the script on my shared hosting (linux) it passes the HTTP_REFFERER just perfectly, but when I run the script on my dedicated ubuntu box with Letsencrypt running, the field for the HTTP_REFFERER is empty.

This is the traker.php

$referer = $_SERVER['HTTP_REFERER'];

$agent = $_SERVER['HTTP_USER_AGENT'];

$ip = $_SERVER['REMOTE_ADDR'];

$redirect = $_GET['page'];


function logger($file, $line) {
  $fh = fopen($file, 'a');
  fwrite($fh, $line."\n");
    fclose($fh);
}

logger("clicks.txt", "Rec"); 
logger("clicks.txt", date("H:i:s d.m.Y")." - [".$_SERVER['REMOTE_ADDR']."] - ".$_SERVER['HTTP_USER_AGENT']." - [".$_SERVER['HTTP_REFERER']."] - "); 

header("Location: $redirect");
?>

This is the redirect_to_destination.php which is loacted in the header and executes with body onLoad="va();"

function va() {
        window.location.href='http://example.com/traker.php?page=http://example.com/end_destination.php?subid=<?php echo $_SERVER["QUERY_STRING"]; ?>';
      }

The last script end_destination.php does the following:

window.location.href='http://affiliate_link.com/?a=756547&c=8786&s1=<?php echo $_GET["subid"]; ?>';

The final link link would be http://example.com/redirect_to_destination?test_subid

The output of the file from the shared hosting is:

17:03:33 07.01.2017 - [01.001.01.001 (example ip)] - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0 - [http://example.com/redirect_to_destination.php?test]

Output of the file running on the dedicated ubuntu box with letsencrypt signing:

00:43:30 08.01.2017 - [01.001.01.001 (example ip)] - Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0 - [] - 

Any idea?

Thanks

Answer 1

https://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html

HTTPS turns off HTTP Referrers to HTTP websites. Why? According to RFC 2616 (HTTP 1.1), this is due to the possibility of sensitive information being encoded in a referring URL:

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

And the partial (not fully supported) solution:

<meta name="referrer" content="always">

I suspect there's a header that can be sent for your redirect (as it won't have HTML for meta tags), but I'm not aware of the exact implementation.