W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [access-control] Update

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 09 Jul 2008 22:31:47 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.ud1km9b664w2qv@annevk-t60.oslo.opera.com>

On Wed, 09 Jul 2008 22:22:52 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> The name "Access-Control-Origin" is IMHO confusing.

It's more or less identical to how it works for Web sockets. (Called  
Websocket-Origin there.)

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

This is exactly how postMessage() works and it seems nice to align with  

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

Well, in the end we want all those concepts implemented in the same way  
everywhere, right? So I'm not sure how this matters.

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

Again, we want to have code reuse and not have separate concepts for same  
origin throughout the browser and Web platform. Since it uses exactly the  
same semantics as several HTML5 features, e.g. postMessage and Web  
sockets, that are also being deployed and shipped by all browsers who plan  
to implement this specification, I don't think this is much of a problem.  
Also, technically it is the superior solution, which should take care of 2.

Anne van Kesteren
Received on Wednesday, 9 July 2008 20:32:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC