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

Anne van Kesteren wrote:
> On Mon, 04 Feb 2008 19:53:01 +0100, John Panzer <jpanzer@acm.org> wrote:
> ...
>> 1. Question: If a cache ends up containing entries for both 
>> (ref,/foo), (ref,/foo/bar/), and processes a non-GET cross-site 
>> request: (ref,/foo/bar/baz.cgi), then it falls under both path 
>> prefixes.   My reading of 
>> http://dev.w3.org/2006/waf/access-control/#access0 is that the access 
>> check process then roughly behaves "as if" all of the Access-Control 
>> information for both /foo and /foo/bar were merged and present in an 
>> Access-Control header for /foo/bar/baz.cgi.
>
> 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.
> ..
>> 2. A subsequent GET of /foo/bar/baz.cgi could add a cache entry 
>> (ref,/foo/bar/baz.cgi), which could provide access control 
>> information for non-GET requests as well.  Would the algorithm above 
>> ignore this cache entry's allow and deny clauses for non-GET 
>> requests, or fold it in?  (I wasn't sure what 'as a prefix' meant in 
>> the paragraph -- it appears to be ruling out an exact full match for 
>> the item itself.)
>
> 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...)

John

Received on Tuesday, 5 February 2008 06:19:40 UTC