- From: John Panzer <jpanzer@acm.org>
- Date: Mon, 04 Feb 2008 10:53:01 -0800
- To: Anne van Kesteren <annevk@opera.com>
- CC: Ian Hickson <ian@hixie.ch>, public-appformats@w3.org
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
Received on Monday, 4 February 2008 18:49:43 UTC