Re: ACTION-462: URI Fragments and HTTP redirects

Julian Reschke wrote:
> On 09.10.2010 04:53, Tim Berners-Lee wrote:
>> GET http://www.example.com/book_ab/chapter_1.html
>> => 301 http://www.example.com/bookshelf/ab#chapter_1
> 
> This happens today, is supported by clients and servers, and has been 
> legal (as per approved RFC 2616 errata) for a very long time.
> 
> The *only* area that we (the HTTPbis WG) really *can* improve is the 
> advice on recombining fragments (which is 
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>).

These problems are primarily because HTTP doesn't fully support 
#fragment identifiers.

There is no one rule fits all solution here, to expand on Yves example 
what about the following request in a browser:

  href="http://www.example.com/book_ab/chapter_1.html#section_1_2_4"
   GET http://www.example.com/book_ab/chapter_1.html
    => 301 http://www.example.com/bookshelf/ab#chapter_1

In this case as an end user I would hope that a the browser first tried 
to display /ab#section_1_2_4 and if not found then /ab#chapter_1, and if 
still not found then just present /ab as-is.

Whereas if the original href had no fragment then one would hope the 
browser tried to present /ab#chapter_1 to the user.

However in another use-case then this really would not be a good 
approach, consider:
   href="/police-files#good_citizens"
   GET /police-files
   => /new-police-files#most_wanted

In yet another (linked-data) use-case where trying to get a description 
for http://example.org/nathan#me then regardless of how the HTTP 
protocol pans out and how many redirections are encountered along the 
way, with fragments or without, then you are still going to be looking 
for a mention of http://example.org/nathan#me in the finally-returned 
content.

Thus it appears to me that the rules on how to recombine fragments are 
entirely context, agent and media type dependant.

Personally I feel that including advice on how to recombine fragments is 
the wrong approach entirely, that having any (or even partial) awareness 
of fragment identifiers in HTTP is a bug and that it would be very wise 
to remove support entirely. Failing that then a note in the spec to say 
that use of fragment identifiers in the Location header is discouraged.

Best,

Nathan

Received on Monday, 11 October 2010 16:48:16 UTC