On Mon, 04 Feb 2008 16:56:58 +0100, Anne van Kesteren <[EMAIL PROTECTED]>
wrote:
I have some small questions/comments below. I'd also like to encourage
everyone to review the proposal. I'm planning to integrate it in the
specification soonish.
I now integrated it into the specification:
http://dev.w3.org/2006/waf/access-control/
Ok, so the idea here is that for /foobar you can't have
Method-Check-Policy-Path: /foo
because /foo/ is not a substring of /foobar. It's not entirely clear to
me what the reason for this is, but if we go for this it would make
sense to me if the actual "method check policy request" would include
the trailing slash as that would avoid a redirect which we may or may
not want to deal with.
This is to ensure that /sample.txt can't set policies for
/sample.txt.foo/sample which makes sense. So I left this in. The slash is
not added for the actual request currently, just for comparison.
Besides pointing to ancestors only (already enforced by the initial
step) the other implication here seems that only one additional request
is warranted. Or do you mean something else by match?
For simplicity I've done it in such a way that redirects are not followed
for the "policy path request". It's just one additional request that
either fails or succeeds.
What about if the initial OPTIONS response doesn't include
Access-Control, etc. Just Method-Check-Policy-Path. That points to /foo/
for instance and /foo/ has Method-Check-Policy-Path set to /foo/, has
the Method-Check-Max-Age header set, and an appropriate Access-Control
header. That seems perfectly acceptable to me. Should we allow that?
I have allowed this. If the policy is in fact located at
Method-Check-Policy-Path performing an access control check on the current
request URI seems wrong. (So even if Access-Control headers are included
they are in fact ignored when Method-Check-Policy-Path is present.)
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
