6

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?

OJFord
  • 10,522
  • 8
  • 64
  • 98
  • I don't know if this is the reason why, but 302 is mostly deprecated in favor of 307. – Nick Humrich Apr 23 '21 at 21:25
  • "The only difference between 307 and 302 is that 307 guarantees that the method and the body will not be changed when the redirected request is made. With 302, some old clients were incorrectly changing the method to GET: the behavior with non-GET methods and 302 is then unpredictable on the Web, whereas the behavior with 307 is predictable. For GET requests, their behavior is identical." [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307) – Lepidosteus Apr 23 '21 at 22:07

3 Answers3

7

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.

Lepidosteus
  • 11,779
  • 4
  • 39
  • 51
  • Thank you! That's.. unfortunate! (I don't understand the post 'the site in question is doing the wrong thing, but we should still be fixing this problem'. To me it doesn't seem it was a problem, except for the unnamed site that wanted to put secret data in query parameters!) – OJFord Apr 24 '21 at 11:12
4

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.

user14473331
  • 155
  • 5
0

This is because browser history does not (have to) conform to cache semantics.

The goal of the history (back button) is to present the user with the page that they would have gotten given the (possibly expired) responses the browser got earlier.

For a more detailed explanation you can look at: https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#history.lists

Thexa4
  • 99
  • 2
  • 4