Forum Discussion
madeye_80512
Nimbostratus
NimbostratusProper use of http redirect codes for temporary redirects?
Hi,
I'm pretty puzzled by the question on how to correclty(*) redirect on a LTM in case of a temporary disruption of service. In case of planned works as well as in case of something seriously wrong we intend to throw the users off onto another URL, i.e. they'd normally access
https://shop.xyz.com/
and we'd temporarily redirect them to another site
https://www.xyz.com/whatever/shopisdown.html
(*)trying to define "correctly": with the least evil effects (caching!) on popular and not so popular browsers or proxys.
The "fallback host" functionality in the http profile uses a 302 redirect when no poolmembers are available, but at least parts of the Internet state that 302 shouldn't be used because it is implemented strangely and was widely abused for somethings.
Triggering http::redirect from an irule throws a 301 which isn't good for the case(caching!).
This would leave a 307. This one is even dubbed "temporary redirect". We didn't try up to now and I'm somewhat scared because I don't feel that it is widely used and well understood.
Anyone with an opinion there?
Best regards
Me.
hooleylistCirrostratus
Hi,
If you want client's and/or intermediate proxies to cache the redirect, you should use a 301 response code. If you don't want the redirect cached, then use a 302.
Can you elaborate on this?
...but at least parts of the Internet state that 302 shouldn't be used because it is implemented strangely and was widely abused for somethings.
I'm not sure what issues you're referring to.
Thanks, Aaron
madeye_80512Hi Aaron,
thank you for your reply and sorry for me being obscure out of time pressure and for asking not well founded questions.
Diving in deeper into the topic on what may be wrong with a 302 I found it connected to FUD regarding Typosquatting / url-hijacking and search engine providers. This (I'm deeply embarrased) happens mostly in the german version of wikipedia *blush*.
It seems that there were (are?) search engines who if www.something.com did a 302 to www.somethingelse.com then searchengines would conclude that the somethingelse site was only temporary and wouldn't index it, thus allowing someone to kick your site out of the searchengines by just 302ing to it.
The worst case for us would be if some major search engine would kick our main site out of their index because we're ourselves redirecting our shop to it during server downtime (see my OP, it is near enough to the truth regarding what we'd intend to do).
You can read the text(s) so that there is common sense on not using 302 any more... but this is very up to interpretional issues.
The other thing is that the http/1.1 RFC2616 itself states things about a 302 being ambiguously implemented so that some browsers would use a GET on the 302s location regardless of the original request method and that this lead to the implementation of 303 (browser should always use a GET on the location) and 307 code (browser should use original method, but verify with the user if method wasn't HEAD or GET).
And for my eye the RFC is VERY obscure there if you try to assume what arbitrary client browsers would do on any of these codes.
But it's not too relevant for our case because we would want the browser to do a request as a GET regardless on what method it intended beforehand.
So the question would rather not be if to use a 307 but if a 303 should be used. And here the RFC states that "most browsers react to a 302 as described for 303".
Given the additional bit that a 302 should be understood also by pre http/1.1 browsers, I agree that probably 302 would be the correct choice, if the concern about URL hijacking can be laid down.
It'd be great if you could ease these doubts.
Best regards and I wish anyone having a great start of a great new year!
Me.