HTTP access control

  • Revision slug: Talk:HTTP_access_control
  • Revision title: HTTP access control
  • Revision id: 286996
  • Created:
  • Creator: myf
  • Is current revision? Yes
  • Comment 55 words added

Revision Content

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

Revision Source

<p>If the property <code>withCredentials</code> is a boolean property, why do the code samples assign the string "true"? Shouldn't the code samples simply assign the boolean value <code>true</code>?</p>
<h3 id="Access-Control-Allow-Origin_is_not_comma_separated!">Access-Control-Allow-Origin is not comma separated!</h3>
<p>It seems that the info in the article is false concerning the value of the <code>Access-Control-Allow-Origin</code> header. The spec says, it has to be either "<code>*</code>" or mirrors the exact value of the <code>Origin</code> 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? --<a href="/User:Manuel_Strehl" rel="custom nofollow">Manuel Strehl</a> 02 November 2009</p>
<p>Tested and reported in <a class=" link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=671608">bug 671608: "Access-Control-Allow-Origin header values comma delimiter / separator"</a> -- Michal Čaplygin, 14 July 2011</p>
<p>Had been <a class=" link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=671608#c1">Clarified</a> there and corrected here by Boris Zbarsky. <strong>Now we clearly know that current implementation expects single value and works only when it matches either "*" or the value of the <a class=" external" href="http://tools.ietf.org/html/draft-abarth-origin-09">Origin request header</a>.</strong> (See also <a class=" external" href="http://www.w3.org/TR/cors/#ref-origin">http://www.w3.org/TR/cors/#ref-origin</a>.</p>
<p>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 <code>Access-Control-Allow-Origin</code> 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 <code>"Access-Control-Allow-Origin: *"</code> 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.</p>
<p>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 <code>Access-Control-Allow-Origin</code> 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.</p>
<p>Also, as of version 1.4.25, lighttpd seems to have no way to test and act on the value of the <code>Origin</code> header, so it seems a bit premature to be enforcing this kind of access control (by default) in UAs. -- Dean Hall, 31 March, 2010</p>
Revert to this revision