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

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.

On Wed, 30 Jan 2008 23:09:57 +0100, Ian Hickson <ian@hixie.ch> wrote:
> When a 200 OK OPTIONS response (i.e. after following redirects) has this
> header, the path in the header is compared to the path of the 200 OK
> response itself. If the path in the header doesn't start with a slash,
> then add a slash at the start of the path. If the path in the header
> doesn't end with a slash, then add a slash to it. If the path, with the
> added slashes if any, is an exact prefix match for the URI of the 200 OK
> response itself, but is not an exact match for that URI, then the whole
> process of sending OPTIONS requests is repeated, with the URI consisting
> of the same scheme, host, and port as the 200 OK response, and the path
> given in the header, without the added slash at the end if one was added.

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.


> Otherwise, if the 200 OK OPTIONS response has this header, but the path  
> in the header, with a slash added at the start if it doesn't have one
> already, is not an exact match for the path of the 200 OK OPTIONS  
> response itself, then apply the generic network error steps. (The header  
> can only
> point to ancestors of the current path.)

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?


> 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.


> [...]

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?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Monday, 4 February 2008 15:53:27 UTC