Re: ACTION-462: URI Fragments and HTTP redirects

On 09.10.2010 04:53, Tim Berners-Lee wrote:
> ...
> 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.

Charlie <-> Bob, I assume.

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

Yves already mentioned a use case:

> => 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

Received on Monday, 11 October 2010 10:16:23 UTC