Access-Control-Allow-Origin header values comma or space delimiter / separator




8 years ago
7 years ago


(Reporter: myf, Unassigned)


8 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



8 years ago
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.
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.
Last Resolved: 8 years ago
Resolution: --- → INVALID


8 years ago
Summary: Access-Control-Allow-Origin header values comma delimiter / separator → Access-Control-Allow-Origin header values comma or space delimiter / separator

Comment 2

8 years ago
Re-tested with

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

No change.
> 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.

Comment 5

8 years ago
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).

Comment 7

8 years ago
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".

Comment 9

7 years ago
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.
You need to log in before you can comment on or make changes to this bug.