URL Fragment and 302 redirects

Update 2022-09-22:

RFC 9110/STD 97 HTTP Semantics (which obsoletes 7231 (and others)), has been published as an INTERNET STANDARD in June 2022. The wording in the newly numbered Section 10.2.2 Location stays the same as before/below.

Update 2014-Jun-27:

RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, has been published as a PROPOSED STANDARD. From the Changelog:

The syntax of the Location header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications as to when use of fragments would not be appropriate. (Section 7.1.2)

The important points from Section 7.1.2. Location:

If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any).

For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other) response containing the header field:

Location: /People.html#tim

which suggests that the user agent redirect to "http://www.example.org/People.html#tim"

Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field:

Location: http://www.example.net/index.html

which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier.

This should clearly answer your questions.

Update END

this is an open (not specified) issue with the current HTTP specification. it is addressed in 2 issues of the IETF httpbis working group:

• #6: Fragments allowed in Location
• #43: Fragment combination / precedence during redirects

#6 allows fragments in the Location header. #43 says this:

I just tested this with various browsers.

• Firefox and Safari use the fragment in the location header.
• Opera uses the fragment from the source URI, when present, otherwise the fragment from the redirect location
• IE (8) ignores the fragment in the location URI, thus will use the fragment from the source URI, when present

Proposal:

"Note: the behavior when fragment identifiers from the original URI and the redirect need to be combined is undefined; current User Agents indeed differ on what fragment takes precedence."

[...]

It appears that IE8 does use the fragment idenfitier from Location (the behavior I saw might be limited to localhost).

Thus we seem to have consistent behavior for Safari/IE/Firefox/Chrome (just tested), in that the fragment from the Location header gets used, no matter what the original URI was.

I therefore change my proposal to document that as expected behavior.

this leads to the most browser compatible and future proof (because this issue will eventually get standardized) answer to your question:

A: fragments from original URLs get discarded.

B: fragments from the Location header are honored.

Posting similar issue with the solution faced by me.

Hope it helps to someone with the similar requirement of preserving hash in IE for 302 redirects.

Adding essential parts of the answer instead of links alone

We use SiteMinder authentication in our application.

I figured out that after successful authentication, SiteMinder is doing 302 redirection to user requested application page by using login form hidden variable value (where it stores user requested URL /myapp/ - without hash fragment since it won't be sent to the server) with name similar to redirect. Sample form below

Since redirect hidden variable value contains only /myapp/ without hash fragment and it's a 302 redirect, the hash fragment is automatically removed by IE even before coming to our application and whatever the solutions we are trying in our application code are not working out.

IE is redirecting to /myapp/ only and it is landing on default home page of our app https://ourapp.com/myapp/#/home.

Have wasted almost a day to figure out this behavior.

The solution is:

Have changed the login form hidden variable (redirect) value to hold the hash fragment by appending window.location.hash along with existing value. Similar to below code

$(function () {
  var $redirect = $('input[name="redirect"]');
  $redirect.val($redirect.val() + window.location.hash);
});

After this change, the redirect hidden variable is storing user requested URL value as /myapp/#/pending/requests and SiteMinder is redirecting it to /myapp/#/pending/requests in IE.

The above solution is working fine in all the three browsers Chrome, Firefox and IE.

Thanks to @AlexFord for the detailed explanation and providing solution to this issue.