The Access-Control-Allow-Origin syntax allows a space separated list of origins, but the "Resource Sharing Check" does not process it as a list, this appears to cause some considerable confusion. I've raised this bug because I believe that this needs to be clarified.

Updating the syntax to disallow space separated lists, as per bug #19920, would indeed remove any ambiguity and avoid needing to update the "resource sharing check." Unfortunately the current inability to specify multiple origins causes people, in some use cases, to inappropriately use *. I'd argue that a space separated list should be supported, and that the "Resource Sharing Check" should be updated to process it in a sensible fashion.

Here's an attempt at justifying my position:

Image+canvas (and now script tag) crossorigin. If I have multiple hosts using images/scripts from another host (think hosted on a CDN, caching reasons, etc), I'm going to want to use *. For many script and canvas use cases this wont be a problem. However, if I have a generated image containing private information, which I want to have cached client side, and then used in canvases on multiple other hosts, I'd need to use * or give up on caching.

Fonts: Mozilla makes use of CORs to restrict usage of web fonts for licencing reasons. If I have multiple hosts using fonts from another of my hosts (CDN, or font license require single domain hosting them), then I have to use *, which defeats the point of this feature.

In both cases CORS has not made my life more difficult than it was in a pre-CORS universe. In the former case what I want is impossible without CORS, and in the latter case using * is equivalent to the behaviour we had before Mozilla implemented this feature. It could, therefore, be argued that leaving well alone (or removing the list syntax) is the right thing to do. On the other hand, I fear that users faced with the promise of CORS solving their problems, yet being unable to specify multiple origins, will resort to use of * where it's least appropriate.

Supporting the space separated list is unlikely to cause existing users to experience unexpected, potentially insecure, behaviour, since the syntax for the field already permits a list.

Certainly something needs to be done to clarify things, even if it is removing the space separated list from the syntax. Expecting people not to be confused by the current situation is unrealistic, even the CORS advocacy page on the W3C wiki gets this one wrong: http://www.w3.org/wiki/CORS_Enabled#How_can_I_participate.3F