Re: ACTION-462: URI Fragments and HTTP redirects

On Fri, 8 Oct 2010, Tim Berners-Lee wrote:

> The whole idea looks worrying to me.
> You are losing information when you throw away "#Frag1".

Yes, but you can't process #Frag1 as you were not able to retrieve A 
anyway (so no Content-Type and rules to get to the data identified by 
A#Frag1)

> Is it a security flaw?
>
> Alice is reading Bob's website document <A> and is
> particularly amused about the section <A#f1>, which is a joke.
> She alerts Charlie that  this: <A#f1> is nonsense. Charlie retrieves
> <A#F1> but Bob's server redirects Charlie's request to <A#F2>.
> <A#F2> is a safety warning.  Charlie concludes that the safety warning
> is nonsense and dies.

Charlie retrieves <A>, Bob's server redirects to <B#F2>, <B#F2> is a 
security warning. Charlie concludes that the safety warning is nonsense 
and dies.

You have the same issue if <A> changes over time and display a safety 
warning before displaying the real content (via scripting for example).

> Well, by quoting the URI A Alice was putting her faith in Charlie anyway,
> so if Charlie is evil Bob is dead anyway.

Right, Bob has control over what happens when Charlie dereference the URI

> Alice expected to be able to use a fragment identifier syntax, and it 
> got suppresses by Charlie.  When is this ever useful?  It seems to have 
> very serious downsides. The fact that browsers do it is no reason at all 
> that they should in the future, unless it serves some useful function.

The fragment identifier might disappear between revisions of the content 
of A anyway, or point to something else, or not being resolvable as the 
Content-Type is different. There is no guarantee that #Frag1 will be 
applicable to <B> anyway, even if the redirect is from <A> to <B> and not 
to <B#Frag2>

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

         ~~Yves

Received on Monday, 11 October 2010 13:40:49 UTC