HTTP access control

If the property withCredentials is a boolean property, why do the code samples assign the string "true"? Shouldn't the code samples simply assign the boolean value true?

Access-Control-Allow-Origin is not comma separated!

It seems that the info in the article is false concerning the value of the Access-Control-Allow-Origin header. The spec says, it has to be either "*" or mirrors the exact value of the Origin header. No word about a comma-separated list. Actually FF 3.5 also has this behaviour. If you throw a comma-separated list onto it, it will ignore the result. Can someone with more knowledge of the internals verify this and correct the article? --Manuel Strehl 02 November 2009

Tested and reported in bug 671608: "Access-Control-Allow-Origin header values comma delimiter / separator" -- Michal Čaplygin, 14 July 2011

Had been Clarified there and corrected here by Boris Zbarsky. Now we clearly know that current implementation expects single value and works only when it matches either "*" or the value of the Origin request header. (See also http://www.w3.org/TR/cors/#ref-origin.

I inadvertently discovered this behavior as well. Firefox completely ignores either comma- or space-separated URLs (that all, individually, meet the spec's requirements as a serialized origin string) as the value of the Access-Control-Allow-Origin header. In fact, I don't see anything in the spec that allows multiple values to be set at all. More troubling is that Firefox seems to cache the results of this header and apply it to all other media on the domain. So even if I set "Access-Control-Allow-Origin: *" for a particular origin/referrer/resource combination and don't explicitly disallow it for a second, Firefox allows other origins(!) to access the second resource.

If the spec does not allow for specifying multiple allowable origins, then, to allow multiple domains (but not all) access to a potentially large combination of different resources in the same resource domain, a UA cannot assume the contents of Access-Control-Allow-Origin applies to anything but the particular origin/referrer/resource combination. Any other behavior seems to be a defect in either the spec or UA behavior, though in this case, I'm not sure which.

Also, as of version 1.4.25, lighttpd seems to have no way to test and act on the value of the Origin header, so it seems a bit premature to be enforcing this kind of access control (by default) in UAs. -- Dean Hall, 31 March, 2010

Document Tags and Contributors

Contributors to this page: Martin Honnen, myf, deanpence, Manuel Strehl
Last updated by: myf,