- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 10 Jul 2008 04:14:03 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: WebApps WG <public-webapps@w3.org>
Anne van Kesteren wrote: > * 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. An alternative syntax I've been thinking about for opting in to cookies is: Access-Control: allow-with-credentials <http://foobar.com> There are a couple of advantages to this syntax. First of all it keeps down the number of headers. Second, and more importantly, it cleanly disallows opting in to cookies while wildcarding. We'd simply make the syntax for the header Access-Control: "Access-Control" ":" allow-rule | allow-with-cred-rule allow-rule: "allow" "<" (URL | "*") ">" allow-with-cred-rule: "allow-with-credentials" "<" URL ">" One, albeit not big, issue with the current proposal is that it allows someone to say. Access-Control-Origin: * Access-Control-Allow-Credentials: true which is somewhat unfortunate. While this can be defined to be rejected by an implementation that supports the Access-Control-Allow-Credentials header. An implementation like XDR which doesn't will still allow the syntax. / Jonas
Received on Thursday, 10 July 2008 11:15:31 UTC