On Wed, 09 Jul 2008 22:22:52 +0200, Jonas Sicking <[EMAIL PROTECTED]> 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/>
