Anne van Kesteren wrote:
On Mon, 04 Feb 2008 19:53:01 +0100, John Panzer <[EMAIL PROTECTED]> 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
