Re: ACTION-462: URI Fragments and HTTP redirects

On Tue, Oct 12, 2010 at 1:40 PM, Nathan <nathan@webr3.org> wrote:
> Jonathan Rees wrote:
>>
>> 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:.
>
> Jonathan,
>
> Apologies but I've missed something along the way, when you refer say `I'm
> confident you're right, but if I were to attempt to champion this cause on
> your behalf` are you referring to:
>
>  (1) deprecating or discouraging use of fragid-in-Location
>
>  (2) creating rules to handle recombining fragments
>
> ?
>
> If not (1), then would you be willing to champion that cause, and would
> anybody here object to (1).
>
> Best,
>
> Nathan

I was responding to Julian, therefore (1).  You may have missed it but
Julian and the HTTP WG have been planning to specify, in 2616's
successor, that the first fragid has to be dropped.  TimBL and I are
asking why, without getting a helpful answer.  I'm willing to
accommodate the WG if referential transparency is kept or architecture
is explicitly scrapped (my conversation with Yves).  You and TimBL
take the hard line which is that we should just preserve the
prohibition in 2616 i.e. (2).

Jonathan

Received on Wednesday, 13 October 2010 11:06:28 UTC