Re: Proposal for ... POST when dealing with large numbers of URIs

On Tue, 05 Feb 2008 07:18:59 +0100, John Panzer <jpanzer@acm.org> wrote:
> Anne van Kesteren wrote:
>> I haven't actually decided how to deal with this situation. My plan was  
>> to actually remove all entries that match a certain URI when entering a  
>> new one. So if /foo/bar/ gives me a cache policy under /foo/bar/  
>> (leaving out the full URI for now) and /foo/baz/ gives me a policy for  
>> /foo/ entering the /foo/ entry would mean deletion of /foo/bar/.
>
> OK.  So if a server isn't consistent in its access policies, then  
> retrieving /foo/bar/ and then /foo/ might accidentally remove a  
> restriction that exists only on /foo/bar/.  I think this is fine as long  
> as the semantics are clearly spelled out for server policy makers; if  
> they did this, their policies would either be redundant or  
> contradictory.  Probably a rule of thumb like "pick a directory level  
> and stick with it for access control policies" would be good.

Yeah.


>> During GET requests no cache information related to cross-site requests  
>> is created. That can only happen as the result of a "special" preflight  
>> OPTIONS request.
>
> Ah, OK.  Why?  (Being able to tell conforming clients to short-circuit  
> disallowed GETs would certainly save us all some DDOS attacks...)

GET is already possible cross-site using <img>, <script>, <form>, etc.  
Putting additional constraints on GET request for protocols following the  
Access Control specification wouldn't make much sense. As currently  
specified nothing is short-circuited, by the way. That is, a failed  
OPTIONS request obviously won't be followed by the actual POST (or other  
non-GET method) request, but you can after that try to make another POST  
request which will result in a new OPTIONS request that might very well  
fail again.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 5 February 2008 10:11:51 UTC