- From: Nathan <nathan@webr3.org>
- Date: Mon, 11 Oct 2010 17:47:27 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: Tim Berners-Lee <timbl@w3.org>, David Booth <david@dbooth.org>, Yves Lafon <ylafon@w3.org>, www-tag@w3.org
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