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: Fri, 8 Oct 2010 12:22:47 -0400
Message-ID: <AANLkTimngioUZ0YivGg8-AJa0yZHbLsAKcM2yAnUS3P7@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: www-tag@w3.org
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").

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.

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
>
>
>
Received on Friday, 8 October 2010 16:23:20 GMT

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