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

On Mon, 04 Feb 2008 16:56:58 +0100, Anne van Kesteren <annevk@opera.com>  
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/>

Received on Tuesday, 5 February 2008 15:07:38 UTC