What's up with named-anchor URLs breaking the back button?<p>I was reading a different thread (http://news.ycombinator.com/item?id=2161405), and when I followed it, I was taken through a series of redirects: https://github.com/documentcloud/backbone/issues#issue/201 -> https://github.com/documentcloud/backbone/issues/201/find -> https://github.com/documentcloud/backbone/issues/issue/201<p>The redirect form the URL with the named anchor redirects to the find URL via JavaScript's window.location property, and the find URL redirects to the final URL via a HTTP Location header.<p>When I reach the final page and click my back button, I'm taken to the named-anchor URL, which initiates the series of redirects, taking me back to the final page.<p>I know the named-anchor URLs are used so that Ajax interactions are reflected in the address bar, but it's annoying when they break expected behavior when used to link directly to a page. (In fairness, this doesn't appear to be a problem in Chrome; I'm using FF)<p>Twitter's also been bad about this recently. (Their URLs look like they're tailored for Google, to me: http://code.google.com/web/ajaxcrawling)<p>Companies should make sure their code doesn't end up trapping users in a redirect loop.<p>In GitHub's case, I believe using location.replace instead of window.location for the first redirect would solve the problem, although I'm not sure because I haven't tried it.<p>Is it possible to have these types of redirects without breaking the back button? If so, why are large sites making this mistake?
yes, its possible. there are lots of sites that do make use of it well/correctly.<p>the reason why its difficult is because it turns the app into a ajax state machine. navigation is much more programmatic, which makes the possibility of something screwing up much higher. especially in a larger, more complex system.