Re: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments)

On Thu, 2010-03-11 at 16:35 +0100, Julian Reschke wrote:
> The other good news is that Firefox, IE and Chrome handle them the
> same way, and that happens to be what makes most sense (IMHO) 

It makes sense from the "let's do the least work to harmonise this"
point of view, but I don't think it makes a lot of sense from an end
user point of view.

Let's say that a long document is published as a series of pages:

 section1.html (containing #subsection1.1, #subsection1.2, etc)
 section2.html (containing #subsection2.1, #subsection2.2, etc)
 ... etc

Later, it is realised that the document is not long enough to justify
the split, so they're merged into a single page:

 all.html (containing #section1, #subsection1.1, etc)

To prevent links from being broken a set of 302 Found redirects are
established:

 section1.html -> all.html#section1
 section2.html -> all.html#section2
 ... etc

Now, imagine a user clicks on a link to <section1.html#subsection1.2>.
Their browser requests <section1.html> and receives a 302 redirect to
<all.html#section1>. 

Which part of the page does it make more sense to scroll the user down
to? #section1 or #subsection1.2? I would argue the latter. The server
could have redirected the browser to the latter fragment itself, if only
it had known the fragment part of the user's original request (though of
course it can't, as the fragment isn't sent over the wire in the
request).

The Firefox/IE/Chrome behaviour I would say perhaps makes sense in the
case of 303 See Other. A 303 response indicates that the resource in the
Location header is a separate resource; a 302 response indicates that
the resource in the Location header is the same resource that was
requested, just in a different place. So with 302 responses, there
should be an expectation that fragment identifiers in the originally
requested resource match any fragment identifiers in the resource from
the Location header.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Friday, 12 March 2010 11:22:11 UTC