Question

There has been a long standing issue with Firefox not loading font from different origin than the current webpage. Usually, the issue arise when the fonts are served on CDNs.

Various solutions has been raised in other questions:

CSS @font-face not working with Firefox, but working with Chrome and IE

With the introduction of Amazon S3 CORS, is there a solution using CORS to address the font loading issue in Firefox?

edit: It would be great to see a sample of the S3 CORS configuration.

edit2: I have found a working solution without actually understanding what it did. If anyone could provide more detailed explanations about the configs and the background magic that happens on Amazon’s interpretation of the config, it will be greatly appreciated, as with nzifnab who put up a bounty for it.

Answer 1

Update September 10, 2014:

You shouldn’t need to do any of the query string hacks below anymore since Cloudfront properly supports CORS now. See http://aws.amazon.com/blogs/aws/enhanced-cloudfront-customization/ and this answer for more info: https://stackoverflow.com/a/25305915/308315

---

OK, I finally got the fonts working using the config below with a little tweak from examples in the documentation.

My fonts are hosted on S3, but fronted by cloudfront.

I’m not sure why it works, my guess is probably that the <AllowedMethod> GET and <AllowedHeader> Content-* is needed.

If anyone proficient with Amazon S3 CORS config can shed some lights on this, it’ll be greatly appreciated.

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>https://mydomain.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Content-*</AllowedHeader>
        <AllowedHeader>Host</AllowedHeader>
    </CORSRule>
    <CORSRule>
        <AllowedOrigin>https://*.mydomain.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Content-*</AllowedHeader>
        <AllowedHeader>Host</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

edit:

Some developers are facing issues of Cloudfront caching the Access-Control-Allow-Origin header. This issue has been addressed by the AWS staff in the link (https://forums.aws.amazon.com/thread.jspa?threadID=114646) below, commented by @Jeff-Atwood.

From the linked thread, it is advised, as a workaround, to use a Query String for differentiating between calls from different domains. I’ll reproduce the shortened example here.

Using curl to check response headers:

Domain A: a.domain.com

curl -i -H "Origin: https://a.domain.com" http://hashhashhash.cloudfront.net/font.woff?https_a.domain.com

Response headers from Domain A:

Access-Control-Allow-Origin: https://a.domain.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
X-Cache: Miss from Cloudfront

Domain B: b.domain.com

curl -i -H "Origin: http://b.domain.com" http://hashhashhash.cloudfront.net/font.woff?http_b.domain.com

Response headers from Domain B:

Access-Control-Allow-Origin: http://b.domain.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
X-Cache: Miss from Cloudfront

You will notice the Access-Control-Allow-Origin has returned different values, which got past the Cloudfront caching.