Last Comment Bug 671608 - Access-Control-Allow-Origin header values comma or space delimiter / separator
: Access-Control-Allow-Origin header values comma or space delimiter / separator
Product: Core
Classification: Components
Component: General (show other bugs)
: 8 Branch
: All Other
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on:
  Show dependency treegraph
Reported: 2011-07-14 11:12 PDT by Michal Čaplygin [:myf]
Modified: 2012-09-18 12:43 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

webfont ("Bowlby One" form ), css and html file from description (36.23 KB, application/octet-stream)
2011-07-14 11:12 PDT, Michal Čaplygin [:myf]
no flags Details

Description User image Michal Čaplygin [:myf] 2011-07-14 11:12:23 PDT
Created attachment 545957 [details]
webfont ("Bowlby One" form ), 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:

§ hosts: test-cdn test-web-1 test-web-2 test-web-3

§ local Apache httpd.conf:
LoadModule headers_module modules/
<IfModule headers_module>
Header add Access-Control-Allow-Origin http://test-web-1,http://test-web-2

§ webroot\test\font.woff: 
(some webfont)

§ webroot\test\style.css:
@font-face {
 font-family: 'font';
 src: url('./font.woff') format('woff');

.font {
 font-family: font;

§ webroot\test\page.html:
<title>Test page</title>
<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
--20:01:25--  http://test-cdn/test/font.woff
           => `font.woff'
Resolving test-cdn... done.
Connecting to test-cdn[]: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
200 OK

Actual results:

Webfont displayed properly just on the first URL.

Expected results:

Webfont displayed properly in first three URLs…

…according : "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: 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.
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2011-07-14 11:46:25 PDT
That documentation is wrong.  Per 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 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.
Comment 2 User image Michal Čaplygin [:myf] 2011-07-14 11:50:01 PDT
Re-tested with

<IfModule headers_module>
Header add Access-Control-Allow-Origin http://test-web-1 http://test-web-2

No change.
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2011-07-14 11:54:42 PDT
> 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.
Comment 4 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-07-14 12:17:36 PDT
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.
Comment 5 User image Michal Čaplygin [:myf] 2011-07-14 12:23:15 PDT
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!
Comment 6 User image Boris Zbarsky [:bz] (still a bit busy) 2011-07-14 12:29:42 PDT
Jonas, that really sucks for fonts (which are static resources that may have licensing constraints on where you can use them).
Comment 7 User image Michal Čaplygin [:myf] 2011-07-14 12:45:56 PDT
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.
Comment 8 User image Boris Zbarsky [:bz] (still a bit busy) 2011-07-14 12:52:38 PDT
I'd watch "Origin", not "Referrer".
Comment 9 User image kadams 2012-09-18 12:38:51 PDT
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.
Comment 10 User image Boris Zbarsky [:bz] (still a bit busy) 2012-09-18 12:43:03 PDT
> 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.

Note You need to log in before you can comment on or make changes to this bug.