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

[AC] Access-Control-Allow-Origin header syntax

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 25 Sep 2008 12:26:05 -0700
Message-ID: <63df84f0809251226w36c91e47w70bdc484eecd9105@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>

Hi webappsers!

So after having gathered some data I'd like to re-raise a topic that
we have discussed a little before: How should the
Access-Control-Allow-Origin response header be compared to the Origin
request header. Specifically, should we do a byte-by-byte string
comparison, or should we parse the two headers are URIs and do a
same-origin check.

There are several ways that two uris can have different string
representations, while still being same-origin. For example all of the
following are equivalent:

http://example.org
http://example.org:80
HTTP://example.org
http://Example.Org

So the question is, if an implementation sends the origin header
'http://example.org' and the server responds with
'HTTP://Example.Org:80', should access be granted or not.

Currently the spec says not, I would argue that this should be changed.

I agree that treating them as opaque strings is somewhat easier to
implement, however in the firefox implementation we are talking about
around 3 vs 8 of code, so I think simplicity of implementation is a
pretty weak argument either way. Both ways are trivial to implement. I
also can't see any security issues either way.

However I think that if we are using URI syntax for these headers we
should treat them as URIs and not as opaque strings. Everywhere else
in the product URIs are parsed and canonicalized before being
compared. We specifically do not use string comparisons. I think for
the sake of consistency with the rest of the web platform we should do
the same here, anything else is just unexpected behavior.

/ Jonas
Received on Thursday, 25 September 2008 19:26:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT