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 <[EMAIL PROTECTED]> 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/>
