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
If the request was a redirect, there should be a header indicating where it was redirected from.
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.
Ensure that you're doing the right sort of redirect. There are redirections for permanent and temporary moves as well as other situation.
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.
Instead of an external redirection, make it an internal redirection. You can track it through your web server's request cycle.
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.
Add path info to the redirection, or maybe query parameters as Sinan suggested.
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.
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.).
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.
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