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.
All of the redirects are 301 redirects. Due to SEO rules added indicators need to be avoided. (Google indexes urls with values separately)
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).
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)
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:On the target side, I detect the
/redirect
in the path, strip it via another redirect, and inject a custom cookie into the response: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:
If the request was a redirect, there should be a header indicating where it was redirected from.
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.).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.
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.
How about:
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.