IE9 blocks download of cross-origin web font

Question

This is driving me crazy.

Just testing a site on IE9 and discovered that the 'live' version is rendering a web font I am using smaller than on the dev version.

Here is a selection of screen grabs:

I am using the Font Squirrel @font-face kit. As you can see, it is fine on Firefox, Chrome and even IE9 when viewing a local version of the site.

The only difference between the local and live versions is that the font is being loaded from a different domain on the live site (I have set up the cross-domain policy correctly, as illustrated by the fact it works on Firefox and Chrome).

I can't remember what it looked like in IE8 (Microsoft, yet again, haven't thought of developers and have installed IE9 over the top of IE8 with no option to run them simultaneously)

The site is at http://enplanner.com so you can view the source.

Any help on this would be most appreciated - thank you in advance.

Edit: I have removed IE9 and discovered that is looks exactly the same on both local and live in IE8. It appears IE8 has a superior rendering engine that is closer to FF/Chrome than IE9. This is quite a depressing discovery.

Answer 1

IE9 supports .WOFF; IE8 does not, and supports only .EOT fonts.

Open the IE9 F12 Developer Tools and you see the following messages:

CSS3117: @font-face failed cross-origin request. Resource access is restricted. 
Neuton-webfont.woff

CSS3117: @font-face failed cross-origin request. Resource access is restricted. 
YanoneKaffeesatz-Regular-webfont.woff

CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable. 
Neuton-webfont.ttf

CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable. 
YanoneKaffeesatz-Regular-webfont.ttf

Examining your HTTP headers, it's clear that your cross-domain access is not configured properly, as there is no Access-Control-Allow-Origin response header on your WOFF files. They're also delivered with the wrong MIME type (text/plain) although that's not causing your problem. However, failure to map woff to the correct MIME type can cause problems as some servers will not serve files with "undefined" extensions and will instead return a HTTP/404 error.

Answer 2

OK, here's what worked. Place the following section in your Apache config for the host you're serving the fonts from:

<FilesMatch "\.(ttf|otf|eot|woff)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "http://mydomain.example"
    </IfModule>
</FilesMatch>

Replace mydomain.example with either your own domain or * (but be careful using * as this means anyone can use your CDN)

The |woff was what I'd forgotten. Doh!

Answer 3

For IIS Add the lines below....works like a charm

---

<system.webServer>
          <httpProtocol>
          <customHeaders>
              <add name="Access-Control-Allow-Origin" value="*" />
              <add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
              <add name="Access-Control-Allow-Headers" value="Content-Type" />
          </customHeaders>
      </httpProtocol>
  </system.webServer>

Answer 4

Regarding the answer of meanstreakuk above, I'd like to complement. We had the same problem and we searched what Google Web Font does. So, we put in our htaccess, this:

Header set Access-Control-Allow-Origin "*"

instead of our domain. If the asterisc, as Google does, it works all the time.

Answer 5

I found one workaround. Added this to htaccess.

BrowserMatch MSIE best-standards-support
Header set X-UA-Compatible IE=8 env=best-standards-support

Answer 6

Check if you can open in IE the file (your-web.example/your-font.woff), If you receive error 404 go to IIS, double-click the "MIME Types" configuration option while having IIS root node selected in the left panel and click "Add..." link in the Actions panel on the right. This will bring up the following dialog. Add .woff file extension and specify application/x-font-woff as the corresponding MIME type.

I use this instructions in this site (Robòtica educativa), I convert my original .ttf font on (http://www.font2web.com/)

Answer 7

An alternative solution to using the Access-Control-Allow-Origin header is to embed the font in your CSS using data:.

Answer 8

It's also worth noting that if your assets are hosted on Amazon AWS S3 that you won't be able to set the headers that the server sends. Instead, you will need to configure the CORS settings on your bucket, as per these instructions:

• http://docs.aws.amazon.com/AmazonS3/latest/UG/EditingBucketPermissions.html
• http://docs.aws.amazon.com/AmazonS3/latest/dev/cors.html

Answer 9

Don't forget to include .svg -- this can be necessary in some instances. Adding it solved the problem in IE 11

<FilesMatch "\.(eot|otf|svg|woff|ttf)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"
    </IfModule>
</FilesMatch>

Answer 10

To implement in ASP.Net you can use this syntax

Response.AppendHeader("Access-Control-Allow-Origin", "*");

Answer 11

I tried everything from modifying my apache config, and .htaccess files with no luck. In the IE development tools I stumbled upon "Document Mode" and the default was IE7. So after some research I found this meta tag:

<meta http-equiv="X-UA-Compatible" content="IE=9">

Now IE 10, and 9 format my website correctly and display all Font Awesome icons correctly.

Hope that helps...

Answer 12

NOT TESTED!
Nginx site file bit for allowing just origin access to font files if your CDN is not public :-) Happy coding

location ~ \.(ttf|otf|eot|woff)$ { 
    Access-Control-Allow-Origin: * 
}

Answer 13

After noticing this error in the console (F12): @font-face failed cross-origin request. Resource access is restricted I discovered that my browser (IE11, emulation: IE9) "blocked content to help protect my privacy". By unblocking the content - click the sign next to the url - it worked like it should.