Why do browsers not keep status 302 pages in back-button history?

user_1446048 0
Viewed 4685

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?

http-status-code-302 browser
3 Answers

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.

user_1057680

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.

user_144733310
user_3371590
Related