Menu
When a request for an HTML page responds HTTP 302 Found (aka 'temporary redirect') FireFox loads the redirect page 'in-place', without keeping the originally opened URL U in 'back-button history'.
One popular use for 302 (and a correct use of the code, I think) seems to be redirecting to a /cookieAbsent page, alerting the user that their browser doesn't 'support' (perhaps more likely the user has disabled) cookies.
The consequence of this browser behaviour is that, if the user decides to enable cookies, reloading of course just reloads (the server couldn't send you back, reliably, if it wanted to) /cookieAbsent which is no good, and the back button goes back to wherever they were prior to opening (whether by hyperlink or typing) the original U. This would make sense to me for 301 Moved Permanently (aka 'permanent redirect'), but seems undesirable for 302, especially when used like this.
If I am implementing a browser - or, perhaps, hoping to report a bug or feature request in an existing one - is this behaviour required by a common specification, or is it simply up to the browser to do as it sees fit?
773
The HTTP error code 302 found indicates that a specific URL has been moved temporarily to a new location. Whenever visitors, Google robots, or other search engines access the original URL, 302 redirect delivers an automatic response indicating a new address. The 302 redirects can benefit a website on several occasions.
The 302 status code is a redirection message that occurs when a resource or page you're attempting to load has been temporarily moved to a different location. It's usually caused by the web server and doesn't impact the user experience, as the redirect happens automatically.
You can find this very relevant bug from 20 years ago (!) on mozilla bugtracker
A short summary of the justification seems to be they did it that way because some websites apparently used 302 the wrong way as a redirect path
/product?limitedtimetoken
302 to
/product?superproduct
302 to
/superproduct
and some got used to the "wrong" behavior of not saving and used it for pretend security
/checkauth
302 to
/connected?gotoaccount
302 to
/account
and while it was "technically right" to save those in history it was just the wrong behavior for end users to have all those middling urls saved, since those were fake 302 that would always redirect in reality.
If you've ever had a case of "the back button of my browser doesn't work it always go back forward" that you can see sometimes it's easy to understand their reasoning.
They mention that it was also what IE and Netscape did, though I could not find the why for those (but I assume it's mostly the same: it would have been bad for the end user to have all that saved in history).
by the way, it makes no sense to undo "this change" - this change is the right fix.. you're right that the site in question is doing the wrong thing, but we should still be fixing this problem.
this patch makes mozilla behave identically to Netscape 4x and IE w.r.t. storing redirect urls in global history. and it is important that we also implement this behavior because (unfortunately) many sites have grown up depending on it for some level of percieved security. this fact is something that can't be changed overnight, nor will it help the reputation of mozilla to not compromise on this issue.
60
Suppose URL $u$ redirects to URL $v$. Suppose also that $u$ is pushed to the history and then $v$ is pushed to the history. When the user clicks the back button, the user will be taken to $u$, which will redirect to $v$. The user will find himself in an infinite loop, making the back button useless.
32
answered Dec 08 '22 19:12
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
