Looks great!
I have a few comments:
The name "Access-Control-Origin" is IMHO confusing. First of all I would
expect "allow" or "grant" or something like that somewhere in the syntax
to indicate that the header is granting access. I have two counter
proposals:
"Access-Control-Allow-Origin" ":" URL | "*"
or
"Access-Control" ":" "allow" "<" URL ">"
I would prefer the latter one as that gives us better opportunity for
future expansions if needed. That way the future expansions can be made
such that existing clients bail due to unrecognized syntax if we so desire.
Similarly, should we rename Access-Control-Credentials to
Access-Control-Allow-Credentials? This feels less important to me.
Lastly, the 'URL' token http://dev.w3.org/2006/waf/access-control/#url
should not be a full URL, and I don't think we want to depend on HTML5
for it either. Currently we seem to be allowing the syntax
Access-Control-Origin: http://foo.com/bar/bin/baz.html
which I think is very bad as it seems to indicate that only that page
would be allowed to POST, which of course isn't something that we can
enforce.
Additionally, the way the spec was written before we could create a
conformat implementation now without having to worry about HTML5
changing things under us.
Note that when I said during the meeting that the URI paring was the
hardest part, I didn't mean that URI parsing was hard. I meant it in the
sense that the spec was so easy to implement that it was even simpler
than URI parsing.
So I strongly think we should bring back the language the spec used to
have for parsing origins. And then the HTML5 spec can refer to the AC
spec for origins if it so desires.
Adding a dependency on HTML5 is bad for a couple of reasons:
1. We want to be able to ship implementations now and not change their
parsing later as that can have security implications.
2. It has been politically hard to add dependencies to unfinished specs.
Weather we think the concerns raised have merit or not, the debate is
likely going to cause the spec to get delayed.
Mostly I care about 1 above.
I haven't reviewed the headers/methods stuff yet. But it looks good at
an initial overview.
/ Jonas
Anne van Kesteren wrote:
Hi,
The WebApps WG had a F2F last week in Seattle. While I'm still a bit
buzzed by the jet lag I managed to "finish" the work I started during
the weekend on updating the Access Control for Cross-Site Requests (AC)
specification to match resolutions and proposals made during the F2F
meeting. The meeting logs of the F2F are not publicly available yet, but
since the editor's draft is, I will summarize what I changed and
depending on whether you trust me or not, you can infer from that what
we decided upon...
The draft is available at the same place as usual:
http://dev.w3.org/2006/waf/access-control/
Here is what I changed:
* <?access-control?> is dropped. Might return in AC2.
* Access-Control is now Access-Control-Origin which takes * or a URL.
In other words, whether or not a site grants access is simplified *a
lot*. Implementors who told me this was the most complex part to
implement can rejoice. This also makes this specification consistent
with Web Sockets and postMessage(), both defined in HTML5.
(Access-Control-Origin is not to be confused with the old
Access-Control-Origin, which is now Origin.)
* Access-Control-Credentials provides an opt in mechanism for
credentials. Whether or not credentials are included in the request
depends on the "credentials flag", which is set by a hosting
specification. Preflight requests are always without credentials.
* Four new headers are introduced to deal with headers and method opt
in. Two request headers (set by the user agent):
Access-Control-Request-Method and Access-Control-Request-Headers. And
two response headers: Access-Control-Allow-Method and
Access-Control-Allow-Headers. (The introduction of these headers also
affected the preflight result cache.)
* The HTTP header blacklist is gone as that is something that affects
all hosting specifications, including same-origin requests, and
therefore is inappropriate in a specification intended solely for non
same-origin requests.
* I've referenced HTML5 for several concepts which hopefully encourages
code reuse in user agents and also makes sure that we don't have to
change if HTML5 does.
* An access control check is now also performed when the redirect steps
are applied to prevent data leakage from intranet pages.
So please review the changes made and the significant revisions to the
processing model. Much appreciated. If you would like to review the CVS
log entries you can do so here (changes since last time start at 1.178,
"MASSIVE CHANGE"):
http://dev.w3.org/cvsweb/2006/waf/access-control/Overview.html
Kind regards,
