19

please read all of this before commenting.

I'm currently working on a large website which is hosted on Amazon Web Services (AWS). This allows us to use scalability features in situations where the website might take a big traffic load.

Originally we started by separating out the code of the website a mix of HTML/PHP/Java etc and have static assets on a separate server. When I first tried using font-face in this setup I found that Firefox and IE would not load the font, and quickly discovered it was a cross-domain issue. There are a variety of solutions to this, which include modifying headers to allow access to the font files. However, the storage system we're using doesn't allow for this type of header modification.

In a bid to see if I could just get the fonts to work across all browsers I moved them and the CSS file that calls them to the same domain as the website. However they still don't seem to load up in Firefox or IE. If I copy the code and run it locally in my documents everything seems fine in all browsers (so the files cannot be corrupt). Firefox is definitely finding the files as I can see them being loaded via FireBug.

I've checked all URLs to make sure they're correct and resolve where they should.

Here's the font-face CSS I'm using with the smiley hack:

@font-face {
    font-family : "AllerRegular";
    src : url('aller_rg-webfont.eot');
    src : local('☺'),
          url('aller_rg-webfont.woff') format('woff'), 
          url('aller_rg-webfont.ttf') format('truetype'), 
          url('aller_rg-webfont.svg#webfontooYDBZYS') format('svg');
    font-weight : normal;
    font-style : normal;
}

The CSS file sits in the same directory as the fonts.

I also have the MIME types set in a .htaccess file which sits in the same folder as the fonts.

AddType application/vnd.ms-fontobject .eot
AddType font/truetype .ttf
AddType font/opentype .otf
AddType font/opentype .woff
AddType image/svg+xml .svg .svgz
AddEncoding gzip .svgz
<FilesMatch "\.(ttf|otf|eot|woff|svg)$">
        <IfModule mod_headers.c>
                Header set Access-Control-Allow-Origin "*"
        </IfModule>
</FilesMatch>

If you have any ideas please suggest.
I've been searching the web for a few days now but all solutions have failed me.

diggersworld
  • 12,770
  • 24
  • 84
  • 119
  • Might be a long shot but, are you behind a proxy ? – Krimo Nov 23 '11 at 16:18
  • Not when running the site in the local development environment. It's a local Tomcat and Apache install. – diggersworld Nov 23 '11 at 16:39
  • Random guess - in CSS, unlike JS, the relative URL's are relative to the path of included CSS file and NOT the document this file is included in. Is that causing this to happen? – avlesh Nov 28 '11 at 05:11
  • I can confirm that the paths to the font files are relative from the CSS file and not the HTML/PHP document. – diggersworld Nov 29 '11 at 09:10
  • See also: http://stackoverflow.com/questions/2892691/font-face-fonts-only-work-on-their-own-domain – pdwalker Oct 22 '14 at 02:30

4 Answers4

14

Currently, serving webfonts from AWS likely won't work in Firefox and IE 9+ because AWS doesn't support the Access-Control-Origin-Header. See this post on the AWS forums. Seems to be a problem for a lot of people.

Update 7/17/12:

As an alternative to AWS, Google's cloud services support cross-origin file serving. I just set up a bucket to serve webfonts, and it seems to be working. See this blog post and the documentation for more info.

Casey
  • 2,025
  • 3
  • 20
  • 22
  • Ah, I hope they implement support for it soon. – diggersworld Mar 14 '12 at 08:54
  • 1
    AWS has added custom origin support in CloudFront. So, you can create a CloudFront distribution with your server as custom origin and serve the font with the `Access-Control-Allow-Origin` header and CloudFront will include that header with cached responses. – DavidJ May 21 '12 at 15:48
  • 1
    AWS now supports custom origin support without Cloudfront using CORS, see http://stackoverflow.com/a/24181448/168012 – Tom Jun 12 '14 at 09:57
  • 1
    it seems that safari still does not send the cross origin headers for font face, so although the font still gets downlaoded and works fine, but S3 does not respond with cors headers unless the browser sends a cross origin request, which means that you might still face issues with preloading cross origin fonts in safari, as there would be a preload request with cors, and a css font face request without CORS, and safari might cache the css response and try to use it later for the preload response which would fail because of missing cors headers – gaurav5430 Sep 20 '21 at 18:10
  • @gaurav5430 I am facing the same issue with Safari only. Any solution to this? – Timo Ernst Jul 15 '22 at 12:03
8

Try do this:

On your server you will need to add:

Access-Control-Allow-Origin

To the header of the font files, so for example if you are using Apache you can add this to the .htaccess:

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

My problem solved with this method.

Parasolx
  • 105
  • 1
  • 2
3

This is possible using S3 without Cloudfront by adding the following CORS configuration.

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

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

http://html5hacks.com/blog/2012/11/18/configure-amazon-s3-for-cross-origin-resourse-sharing-to-host-a-web-font/

http://blog.blenderbox.com/2012/10/12/serving-font-face-fonts-to-firefox-from-an-s3-bucket/

Tom
  • 12,591
  • 13
  • 72
  • 112
2

You may well need to add support for the MIME types on the new hosting environment.

Take a look at:

http://www.jbarker.com/blog/2011/web-fonts-mime-types

joshcomley
  • 28,099
  • 24
  • 107
  • 147