Response.Redirect strips Header Referrer - Possible to Add it Back?

Question

I'm using a Response.Redirect to redirect users to another server to download a file, and the other server is checking the header to ensure it came from the correct server... however it seems Response.Redirect strips the headers from the Response.

Does anybody know how i can add the headers back? I've tried:

Response.AddHeader("Referer", "www.domain.com");

But the receiving page tests false when i check if the Referrer header is set.

Any suggestions how i can get this working, other than displaying a button for the user to click on (i'd like to keep the url hidden from the user as much as possible).

Solution 1

There is an HTML hack available.

<form action="http://url.goes.here" id="test" method="GET"></form>
<script type="text/javascript">
  document.getElementById("test").submit();
</script>

If you need to trigger that from a code behind, that can be done too:

Response.Write( @"<form action='http://url.goes.here' id='test' method='GET'></form>
                  <script type='text/javascript'>
                     document.getElementById('test').submit();
                  </script> ");

As Inkel might point out, that is a loose interpretation of the Referer[sic] spec. It will do what you want though.

Solution 2

That will go against the Referer (sic) header definition:

The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.)

If you are redirecting this is clearly not the case to add this header.

If you need this information try with a cookie or some session variable, or even better a variable in the URL as you have already been told.

Solution 3

Is Server.Transfer an option?

There are some caveats though that you will need to look into. E.G. Keeps the original URL, Authorization, etc... More details in the link.

Keeping the original URL may be advantageous in this circumstance.

Solution 4

I know that this is old, but I just came across it while trying to do a similar thing.

I didn't want to add it to the URL as it kinda polluted the URL with stuff I didn't want in there. Also, I didn't want people to accidently bookmark that URL. Therefore, I used Cookies to add my data;

string token = vwrApi.GetAuthenticationToken(userId);
Response.Cookies.Add(new HttpCookie("VwrAuthorization", token));
Response.Redirect(returnUrl, true);

Of course this is reliant on your ability to change where the destination server looks for the information, but it is another option at least.

Solution 5

I don't think it's possible. What you are sending back to the client is a Location header that tells the client to load the page referred to instead of the page it originally requested. In this case the client is not coming from a link and thus does not set the referrer header. It's basically as if the user typed the redirect url in the location bar in his browser.

You may be able to save the referrer in the session, or encode it in the URL as a query parameter. Like the Forms login does with ReturnUrl.

View more solutions

Comments

[Jeeby]

Server.Transfer is only an option when its on the same server, correct? In this case, I need to redirect to a different server, so probably not going to work :(

[Leandro López]

What if the user is making two request concurrently? I know, it is mostly impossible to happen, but who knows...

[Lazarus]

It's a good question. I suspect the second request will overwrite the Session["referrer"] value that I've created, however my code will have already stored the first request in a DB table so I still have it for reporting purposes but overkill in this scenario.

[EMP]

Yep, that's the only thing that worked for me in both IE7 and FF3

[Marcel]

This does not work the way it corresponds to the question. The redirected request does not have the expected referer string (You said that though).

[Liam]

you need to escape the " in your c#

[Mladen B.]

you need to add extra security handling around that parameter, since a client can freely tamper with it

[Martin Brown]

Well that depends on exactly what is being done. It's a bit hard from the original question to know if it is a problem or not. There is little to go on as to what is being secured and why. Or if it is a security check at all.