URL Fragment and 302 redirects

It's well known that the URL fragment (the part after the #) is not sent to the server.

I do wonder though how fragments work when a server redirect (via HTTP status 302 and Location: header) is involved.

My question is really two-fold:

1. If the original URL had a fragment (/original.php#foo), and a redirect is made to /new.php, does the fragment part of the original URL simply get lost? Or does it sometimes get applied to the new URL?
   Will the new URL ever be /new.php#foo in this case?

2. Regardless of the original URL, if the server redirects to a new URL with a fragment (/new.php#foo), will the fragment get "honored"? Or does the server really have no business interfering with the fragment at all -- and will the browser therefore ignore it by simply going to /new.php??

Solution 1:

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.

Solution 2:

Safari 5 and IE9 and below drop the original URI's fragment if a HTTP/3xx redirect occurs. If the Location header on the response specifies a fragment, it is used.

IE10+, Chrome 11+, Firefox 4+, and Opera will all "reattach" the original URI's fragment after following a 3xx redirection.

Test page: http://www.webdbg.com/test/redir/fragment/.

See further discussion of this issue at http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx

Solution 3:

Just to let you know, here you can find proper spec. by w3c defining how all should behave: http://www.w3.org/TR/cuap#uri - clause 4.1 - see below:

When a resource (URI1) has moved, an HTTP redirect can indicate its new location (URI2).

If URI1 has a fragment identifier #frag, then the new target that the user agent should be trying to reach would be URI2#frag. If URI2 already has a fragment identifier, then #frag must not be appended and the new target is URI2.

Wrong: Most current user agents do implement HTTP redirects but do not append the fragment identifier to the new URI, which generally confuses the user because they end up with the wrong resource.

References:

HTTP redirects are described in section 10.3 of the HTTP/1.1 specification [RFC2616]. The required behavior is described in detail in "Handling of fragment identifiers in redirected URLs" [RURL]. The term "Persistent Uniform Resource Locator (PURL)" designates a URL (a special case of a URI) that points to another one through an HTTP redirect. For more information, refer to "Persistent Uniform Resource Locators" [PURL]. Example:

Suppose that a user requests the resource at http://www.w3.org/TR/WD-ruby/#changes and the server redirects the user agent to http://www.w3.org/TR/ruby/. Before fetching that latter URI, the browser should append the fragment identifier #changes to it: http://www.w3.org/TR/ruby/#changes.