How can I detect if page was requested via a redirect?

Question

On a client's website there are loads of redirects going to a particular page. This page somehow needs to have a way detecting whether the request was direct (URI typed in manually) or a redirect.

1. All of the redirects are 301 redirects. Due to SEO rules added indicators need to be avoided. (Google indexes urls with values separately)

2. I have tried checking all environment variables but all of them are empty (which assume is normal) and in this respect internal redirects are not any different (I reckon).

3. Detection needs to happen real time so log files are not an option.

The process in short, parameters are registered in cookies via a script, then it 301 redirects to the page where the content is cookie driven. While cookies are registered the content won't change back to original when someone retypes the address in the address bar.

I hope this makes sense.

PREVIOUSLY: I was thinking about status codes, but I am not sure if there is a way to read that on the destination page or not. (We've clearified that it won't work)

Solution 1

Inspired by Brian I toke a step back and looked at what exactly is causing my problem.

There may not be an answer to this question but there is a solution that partially solves problem. By using session cookies the modified content will only exist for that particular session so next time the original content becomes accessible again. This doesn't change the fact that re-enterying the url in the addressbar will still result in the page using the cookie.

Thank you all for trying to help.

Solution 2

How about:

my $cgi = CGI->new;

print $cgi->redirect(
    'http://example.com/this/page/that.html?redirect=yes'
);

What ever mechanism you are using to distinguish between redirects can then look at the query string to decide. Of course, this does not prevent users from bookmarking the URL with the redirect=yes etc.

You could try the referer header, but that has its own problems.

Solution 3

Depending on the browser and intermediate proxies, several things can happen. However, in most cases you can't depend on any one thing. The status codes are something the server sends back to the browser, so you won't get those in a request.

You don't say what problem you are trying to solve or why this bit is important. What problem are you trying to solve?

Instead of relying on something you don't control, turn it into something you can control.

1. Ensure that you're doing the right sort of redirect. There are redirections for permanent and temporary moves as well as other situation.

2. If you don't need the data in real time, you can figure out from log files. This is handy if you're trying to figure out traffic patterns, but not so useful in real time.

3. Instead of an external redirection, make it an internal redirection. You can track it through your web server's request cycle.

4. Set a cookie on the external redirection then look for it in the next request. This won't catch the people who don't set cookies though.

5. Add path info to the redirection, or maybe query parameters as Sinan suggested.

Solution 4

This is what I recently did to detect a redirect and expose it as a custom request header to the application: X-Redirect: 1 (using Apache's mod_rewrite and mod_headers).

On the source side, I redirect all requests to the target server by prepending an additional /redirect to the URL path:

RewriteRule ^/(.*) http://target-server.com/redirect/$1 [L,R=permanent]

On the target side, I detect the /redirect in the path, strip it via another redirect, and inject a custom cookie into the response:

RewriteRule ^/redirect/(.*)$ /$1 [R=permanent,L,CO=redirect:1:target-server.com:86400:/]

Also on the target side, I convert the cookie into an environment variable, "disable" the cookie, then convert the env variable into a custom request header:

RewriteCond %{HTTP_COOKIE} redirect=1 [NC]
RewriteRule ^(.*)$ /$1 [L,CO=redirect:0:target-server.com:86400:/,E=redirect:1]
RequestHeader set X-Redirect 1 env=redirect

Solution 5

I don’t think there’s a way to do that. The only indicator I can imagine is the Referer header field. But it seems that it’s only sent if the request was initiated on a non-HTTP way (clicking a link, form submission, meta refresh, etc.).

View more solutions

Comments

[Gumbo]

Well, prove me otherwise, Mr. Down-Vote.

[Zhaph - Ben Duguid]

Certainly if they can update all the requests to include a known query string that would help, but as you point out, if the user bookmarks that URL or worse still links to it you'd need to check something else (like the referer info - and check the contents not just that it exists)

[G Berdal]

I thought so too. But I don't seem to find a way to get to it. HTTP_REFERER doesn't show in this case.

[brian d foy]

@Zhaph: the idea is to intercept the request and transform it. Even if they try to get the old URL, they still get redirected with the extra info. If you're hunting down parts of the application that link to that URL, log file analysis and something like grep can help. :)

[brian d foy]

"Should" is a strong word. The HTTP spec doesn't say "should". There might be a header, but it's not a requirement or even a recommendation.

[G Berdal]

I mean, it seems you are right about not getting a referer in case of a redirect.

[G Berdal]

Thanks for all your suggestions but none of them realy works in this case. Redirects are all permanent 301 redirects and cannot be anything else due to SEO reasons. Data is needed real time. Internal redirection doesn't seem to make a difference at the destination or at least not regarding headers. The problem with cookies is exactly what you mentioned. Parameters are not allowed due to Google indexing methods.

[brian d foy]

I was mostly thinking about these as internal things using URL translation that the outside world never sees.