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
that.
> 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
<http://annevankesteren.nl/>
<http://www.opera.com/>