- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 25 Sep 2008 12:26:05 -0700
- 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 UTC