Bug 19506 – When hitting 302 pages the originating page is saved to history rather than the redirected page

• Status: NEW
• Component: History

[Dave Verwer]

Steps to reproduce.

1. Go to http://en.wikipedia.org
2. Click on the Random Article link on the left hand side bar
3. Click it again...
4. and again...
5. click Back in Safari

The user expectation would be that the history would go back through the pages that have been viewed, however the history obviously only contains the http://en.wikipedia.org/wiki/Special:Random location which is even seen as a duplicate and rather than seeing 3 different random pages (which would also be unexpected behaviour) the history goes back to the original page http://en.wikipedia.org.

Firefox handles this "correctly" where correctly means as an average user would expect. Opera also handles this issue correctly.

[Alexey Proskuryakov]

It seems that WebKit is handling this "correctly" where correctly means being in accordance with to RFC 2616: "10.3.3 302 Found. The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests."

[Dave Verwer]

That is why i used "correctly", the RFC may say that but in terms of user experience this is far from ideal.

[Du Song]

//bump

This is *very* annoying bc the shortened urls are getting more and more popular among social networks (e.g. fb.me , t.co and youtu.be) in the last few yrs.
A shortened URLs usually don't have a title, so the saved history items contains nothing meaningful but a hash string. This makes the browser history and omnibar useless in many cases.

[Alexey Proskuryakov]

This still seems broken, possibly even regressed. The history doesn't contain any intermediate pages now.