URL hash is persisting between redirects

Question

For some reason, non IE browsers seem to persist a URL hash (if present) when a server-side redirect is sent (using the Location header). Example:

// a simple redirect using Response.Redirect("http://www.yahoo.com");
Text.aspx

If I visit:

Test.aspx#foo

In Firefox/Chrome, I'm taken to:

http://www.yahoo.com#foo

Can anyone explain why this happens? I've tried this with various server side redirects in different platforms as well (all resulting in the Location header, though) and this always seems to happen. I don't see it anywhere in the HTTP spec, but it really seems to be a problem with the browsers themselves. The URL hash (as expected) is never sent to the server, so the server redirect isn't polluted by it, the browsers are just persisting it for some reason.

Any ideas?

Answer 1

This is an aspect that was not covered by previous HTTP specifications but has been addressed in the later HTTP development:

If the server returns a response code of 300 ("multiple choice"), 301 ("moved permanently"), 302 ("moved temporarily") or 303 ("see other"), and if the server also returns one or more URIs where the resource can be found, then the client SHOULD treat the new URIs as if the fragment identifier of the original URI was added at the end.

The exception is when a returned URI already has a fragment identifier. In that case the original fragment identifier MUST NOT be not added to it.

So the fragment of the original URI should also be used for the redirection URI unless it also contains a fragment.

Although this was just a draft that expired in 2000, it seems that the behavior as described above is the de-facto standard behavior among todays web browsers.

@Julian Reschke or @Mark Nottingham probably know more/better about this.

Answer 2

From what I have found, it doesn't seem clear what the exact behaviour should be. There are plently of people having problems with this, some of them wants to keep the bookmark through the redirect, some of them wants to get rid of it.

Different browsers handle this differently, so in practice it's not useful to rely on either behaviour.

It definitely is a browser issue. The browser never sends the bookmark part of the URL to the server, so there is nothing that the server could do to find out if there is a bookmark or not, and nothing that could be done about it reliably.

Answer 3

I suggest that this is the correct behaviour. The 302 and 307 status codes indicate that the resource is to be found elsewhere. #bookmark is a location within the resource.

Once the resource (html document) has been located it is for the browser to locate the #bookmark within the document.

The analogy is this: You want to look something up in a book in chapter 57, so you go to the library to get the book. But there is a note on the shelf saying the book has moved, it is now in the other building. So you go to the new location. You still want chapter 57 - it is irrelevant where you got the book.