W3C home > Mailing lists > Public > www-tag@w3.org > October 2010

Re: ACTION-462: URI Fragments and HTTP redirects

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 12 Oct 2010 06:55:15 -0400
Message-ID: <AANLkTikp8moN14FrihoR_6CykdDLgFGORcaFk3Gci0r-@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Tim Berners-Lee <timbl@w3.org>, David Booth <david@dbooth.org>, nathan@webr3.org, Yves Lafon <ylafon@w3.org>, www-tag@w3.org
On Mon, Oct 11, 2010 at 6:15 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
...
> Yves already mentioned a use case:
>
>> 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>).
>
> Best regards, Julian

With all due respect... I'm confident you're right, but if I were to
attempt to champion this cause on your behalf, someone might challenge
me to exhibit not a theoretical use case, but an actual case in the
wild, one that would break if 2616 were enforced.  Surely there is
one, or this issue would never have been raised?  And if there is one,
you should be able to provide me with a resolving URI? Not only would
such a URI advance the cause, but it might also give us details about
what actual needs are out there, and perhaps shed light on Tim's
question about information loss.

We've come across two in-the-wild cases relating to linked data, but
these don't qualify because (a) the linked data world is not the main
concern for 2616, and (b) each case represents an error that can be
easily fixed without the use of fragid-in-Location:.

Best
Jonathan
Received on Tuesday, 12 October 2010 10:55:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:28 GMT