Re: ACTION-462: URI Fragments and HTTP redirects

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