Created attachment 545957 [details]
webfont ("Bowlby One" form http://www.google.com/webfonts ), css and html file from description
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110713 Firefox/8.0a1
Build ID: 20110713030741
Steps to reproduce:
§ local Apache httpd.conf:
LoadModule headers_module modules/mod_headers.so
Header add Access-Control-Allow-Origin http://test-web-1,http://test-web-2
src: url('./font.woff') format('woff');
<link rel="stylesheet" type="text/css" href="http://test-cdn/test/style.css">
<span class="font">mmm</span> - should not look the same as above
§ Accessed in Fx 5.0.1 and 8.0a1
§ Just a check, see line 8 :
C:\>wget http://test-cdn/test/font.woff -S --spider
Resolving test-cdn... done.
Connecting to test-cdn[127.0.0.1]:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 200 OK
2 Date: Thu, 14 Jul 2011 18:01:26 GMT
3 Server: Apache/2.2.8 (Win32) PHP/5.2.5
4 Last-Modified: Thu, 14 Jul 2011 17:42:17 GMT
5 ETag: "3c00000000810b-8de0-4a80b0dda0805"
6 Accept-Ranges: bytes
7 Content-Length: 36320
8 Access-Control-Allow-Origin: http://test-web-1,http://test-web-2
9 Keep-Alive: timeout=5, max=100
10 Connection: Keep-Alive
11 Content-Type: text/plain; charset=utf-8
Webfont displayed properly just on the first URL.
Webfont displayed properly in first three URLs…
…according https://developer.mozilla.org/en/HTTP_access_control#Simple_requests : "The Access-Control-Allow-Origin header should contain a comma separated list of acceptable domains."
Fact that it does not work this way was described in 2009 at its talk page: https://developer.mozilla.org/Talk:En/HTTP_access_control. Searching trough bugzilla for permutations of "Access-Control-Allow-Origin", "delimiter", "separator" and "comma" gave me no valid result, so I am creating this bug.
That documentation is wrong. Per http://tools.ietf.org/html/draft-ietf-websec-origin-02#section-7.1 the BNF for the origin list is:
origin-list = serialized-origin *( SP serialized-origin )
where "SP" is a space. So it's a single-space-separated list, not comma-separated.
But that's the syntax. The processing model is http://dev.w3.org/2006/waf/access-control/#resource-sharing-check-0 and defines just a case-insensitive string match.
The earlier spec prose that's normative for the server says that the Access-Control-Allow-Origin header must match the Origin header in the request for access to be allowed. The Origin header in the request may be a whitespace separated list per the IETF draft.
So as far as I can tell, our behavior here is correct. I've fixed the documentation.
That said, this seems like a huge pain; it means that allowing access to a small whitelist of origins _requires_ server-side scripting. Jonas, Anne, that seems suboptimal.
Header add Access-Control-Allow-Origin http://test-web-1 http://test-web-2
> No change.
Yes, see the "processing model" thing above. If the value sent in Access-Control-Allow-Origin is not a case-insensitive string match for the exact value sent in Origin, the client must disallow access to the resource as the spec stands now.
That was an intentional choice.
In almost all cases you either have a static resource which doesn't need protecting since it can be read using wget anyway, or you have a dynamic resource in which case you're doing scripting anyway.
There are exceptions, but they didn't seem common enough to optimize for.
Oh, I've got it, sorry (I spent a whole day with this issue and am a bit tired right now.) I'm glad that documentations is accurate now.
I'm wondering if some Apache SetEnvIf Referer magic could be used for real-world whitelisting…
Anyway, thanks a lot for quick clarification!
Jonas, that really sucks for fonts (which are static resources that may have licensing constraints on where you can use them).
Boris: that's exactly what I meant; I am working on webpages spread on about twenty domains and I am using one extra as a static container for all design graphics, stylesheets and webfonts. For design it works well, but for webfonts it works in all-except-Firefox browsers (other browsers ignore Control Origin header completely). Yes, I may use just Access-Control-Allow-Origin *, but since fonts my client uses are licensed, I wanted to whitelist relevant domains for a sake of following font vendors TOS. As I see now, the only solution that remains is both
Access-Control-Allow-Origin * AND some server-side referrer-watching magic.
I'd watch "Origin", not "Referrer".
Wow, seriously? I'll second comment #6. This issue sucks for fonts. Firefox requires the header to read webfonts, but won't allow multiple domains, which is perfectly valid by the spec. I'm having a hard time understanding why the bug is invalid.
> but won't allow multiple domains, which is perfectly valid by the spec.
It's valid to _send_ per the IETF syntax spec. But it does not actually allow access per the W3C CORS spec. See comment 1 and the links therein. That's why this bug is invalid: because we're doing exactly what the CORS spec says to do. If you think the result is suboptimal (which I do), please raise the issue on the CORS spec.