W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

RE: P3P - Feedback on Access Control

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 25 Jan 2008 22:05:33 +0000 (UTC)
To: "Close, Tyler J." <tyler.close@hp.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <Pine.LNX.4.62.0801252158560.20219@hixie.dreamhostps.com>

On Fri, 25 Jan 2008, Close, Tyler J. wrote:
> 
> Well, imagine a SimpleDB-like service that didn't abuse GET in this way; 
> say it used the ATOM publishing protocol. In this case, each unit of 
> information has its own URI and is mutated using a non-GET operation.

So each resource requires one additional round-trip. Unless you have a 
very unusual situation where you are manipulating a lot of resources only 
once, the cost is minimal.

I do not believe that we should change the API to optimise for the one 
case of an API that involves a lot of non-GET requests to unique 
resources. It is trivial to optimise the server's protocol in this case 
anyway (just use one URI and put the parameters in the body), and this 
more closely matches what most people will be doing anyway.


> Surely we don't want to encourage the abuse of GET to avoid this 
> performance penalty.

Of course not. However, I don't believe the case you are describing is 
common. (I have no idea what evidence would convince you of this, so I'm 
not going to try to prove it.)


> The WG's current proposal also results in a tragically humourous network 
> protocol where the server tells the client to PUT to a URL and then the 
> client asks if it is allowed to PUT to that same URL, and repeats this 
> question for every URL it receives from the server.

I would far rather have this situation than the situation where the client 
does a series of cross-domain PUTs that are unexpected.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 25 January 2008 22:05:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC