- From: Sunava Dutta <sunavad@windows.microsoft.com>
- Date: Wed, 9 Jul 2008 14:54:17 -0700
- To: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>
- CC: WebApps WG <public-webapps@w3.org>
Jonas said: "> 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." I prefer Access-control: * Access-control: <URL> In the future, denying a particular URL can be represented using the "-" sign? Access-control: -<URL> Thoughts? > -----Original Message----- > From: public-webapps-request@w3.org [mailto:public-webapps- > request@w3.org] On Behalf Of Jonas Sicking > Sent: Wednesday, July 09, 2008 1:23 PM > To: Anne van Kesteren > Cc: WebApps WG > Subject: Re: [access-control] Update > > > 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, > > > > > >
Received on Wednesday, 9 July 2008 21:55:16 UTC