Re: ACTION-462: URI Fragments and HTTP redirects

Jonathan Rees wrote:
> On Mon, Oct 11, 2010 at 6:15 AM, Julian Reschke <> wrote:
> ...
>> Yves already mentioned a use case:
>>> GET
>>> => 301
>> 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
>> <>).
>> 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:.


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).



Received on Tuesday, 12 October 2010 17:41:03 UTC