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

Re: ACTION-462: URI Fragments and HTTP redirects

From: Yves Lafon <ylafon@w3.org>
Date: Mon, 11 Oct 2010 09:13:58 -0400 (EDT)
To: Jonathan Rees <jar@creativecommons.org>
cc: www-tag@w3.org
Message-ID: <alpine.DEB.1.10.1010110908300.13452@wnl.j3.bet>
On Fri, 8 Oct 2010, Jonathan Rees wrote:

> Can you give me an extant URI for which this makes a difference? I've
> been repeatedly assured that they exist, but I don't think anyone has
> exhibited one here.
> I'm uneasy because your rule contradicts the architecture. Supposedly
> URIs "identify" resources. The rule makes fragids resolve according to
> different mechanisms depending on the context of use, a violation of
> referential transparency (a.k.a. "uniformity").

A fragid identify a subresource, and is resolved after the derefencing of 
the "main" resource. That's where the main difference is, not as a name
but when you dereference.

> There is another way to achieve the same effect that doesn't have this
> problem. You could stipulate that when you try to resolve a fragid
> relative to an element or other document part (as opposed to the usual
> case where you're resolving relative to an entire document), you get
> the whole document part, i.e. the fragid is ignored.

If my reading is right, you say that in case of a redirect, you always 
drop the original fragment identifier. That would be indeed another 
solution, like saying that a fragment (a sub-resource) is always relative
to the "main" resource, and in the case of the redirect, the 
sub-resource->main resource link is broken, so there is no reason it will 

> Jonathan
> On Fri, Oct 8, 2010 at 9:51 AM, Yves Lafon <ylafon@w3.org> wrote:
>> On Mon, 4 Oct 2010, Yves Lafon wrote:
>>> My position on this is that:
>>> * Fragments in redirects have a real value and are already used.
>>> * Fragment recombination can be hard and impossible in the general case
>>> * We need to define a good story for applying a fragment to a redirected
>>> URI
>>>  with a different fragment.
>> And the proposal is:
>> << When retrieving a resource A leads to a redirect to an URI B containing a
>> fragment, any existing fragment on A MUST be dropped in favor of B's
>> Fragment >>
>> Original URI: A#Frag1
>> -> GET A
>> -> 3xx Location: B#frag2
>> Final URI -> B#frag2
>> Cheers,
>> --
>> Baroula que barouleras, au tiéu toujou t'entourneras.
>>        ~~Yves

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Monday, 11 October 2010 13:13:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:08 UTC