Anne van Kesteren wrote:
...
Otherwise, if the 200 OK OPTIONS response has this header, and the
path in the header, with a slash added at the start if it doesn't
have one
already, is an exact match for the URI of the 200 OK OPTIONS response
itself, then continue as currently specified, except that the
Access-Control allow and deny rights must be applied to all paths that
have the path of this 200 OK response, with a trailing slash added if
not
already present, as a prefix, and that, if sent, the non-GET request
must
be sent to the URI of the first 200 OK response for this invocation
of the Cross-site Non-GET Access Request algorithm (not to the final
location of
the policy).
My plan is to integrate this in the current proposal for the cache so
it will not be exactly like this. That is, allow and deny clauses are
followed but the cache only holds the result for a (referrer root,
request URI substring) combination.
(I'm assuming substring == path prefix.)
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. However,
Access-Control information that might be present on /foo/bar/baz.cgi
itself is not used since no OPTIONS request is sent to that resource.
Is this right?
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.)
-John
