Will a 302 redirect maintain the referer string?
I don't know about the 302, but I tested the 301 on some browsers today, here the results:
SCENARIO: user clicks link on domainX that points to domainA. domainA does a 301 redirect to domainB.
- IE8
referer
when landing on domainB is: domainX (even when using InPrivate browsing and even when user opens link in new tab) - Safari4
referer
when landing on domainB is: domainX (even when user opens link in new tab) - FF3.6.10
referer
when landing on domainB is: domainX (even when user opens link in new tab) - Chrome5
referer
when landing on domainB is: domainX (unless user opens links in new tab) - Chrome26
referer
when landing on domainB is: domainX (even when the user opens links in new tab)
Short answer is it's not specified in the relevant RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 either for the Referer header or the 302 status code.
Your best bet is to do a test with several browsers and see if there's a consensus behaviour.
For full belt and braces, encode the original referrer in the redirect URL so you can guarantee to retrieve it.
Good question. In this case, the sending of the referer depends entirely on the browser (because the browser is told to make another request to the new resource).
RFC 2616 remains silent about the issue:
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
I wouldn't trust the browser to send the right referer along. I bet there is at least one that sends something different than the others.
Workaround
If you can, why not add a ?override_referer=<old_url>
parameter to the URL you redirect to, and parse that value instead of HTTP_REFERER.
That way you can be sure to always get the right result, and you're not losing anything in security: The referer can be faked either way.