Re: ACTION-462: URI Fragments and HTTP redirects

On 2010-10 -08, at 13:36, David Booth wrote:

> On Fri, 2010-10-08 at 17:46 +0100, Nathan wrote:
>> Julian Reschke wrote:
>>> On 08.10.2010 15:51, Yves Lafon 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
>>> 
>>> We probably should mention that this is what UAs actually *do*, and have 
>>> been doing for a long time 
>>> (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>).
>> 
>> whereas, to the best of my knowledge this isn't what RDF tooling and 
>> similar do if dereferencing http://example.org/A#frag1 then that's what 
>> you'll be looking for in the content returned.
>> 
>> unsure if that adds anything to the debate ;)
> 
> In the RDF case of 303 redirects, as described in
> http://www.w3.org/TR/cooluris
> the original URI A#Frag1 denotes something, and the content retrieved
> from the new URI B#frag2 is intended to *describe* what A#Frag1 denotes.
> So I don't think there is a conflict with the above proposal.  That
> proposal only affects how the content is *retrieved* -- not how the
> retrieved content is used in describing the meaning of A#Frag1.  

1. I don't know of anyone using this with 303, so this may just
be adding complexity we don't need to consider.

2. To go doen your reasoning though, indeed <B#Frag2> must
be *document describing* <A#Frag1>.  This does NOT mean
that <B> is a document describing <A#Frag1>.
The client, you could argue, should look at <B> to get info about
the document <B#Frag2>, and use that info to retrieve it
(or query it or generate it  etc), and *then* that document can be looked at
to get info on <A#Frag1>.  Which is another level of indirection,
and not somewhere I wanted to go!

The whole idea looks worrying to me.
You are losing information when you throw away "#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.

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

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.

Tim

Received on Saturday, 9 October 2010 02:54:05 UTC