Thursday 12 September 2013

How to fix H&FJ webfonts that aren't working with AWS S3 in production mode.


Set the content-type headers correctly when uploading the Webfont data folder.

Not Working

I have to say, I was excited when Hoefler & Frere-Jones launched their [web font offering]; albeit a little late in the day. However that excitement drained a little today when I had to put the fonts into production as SoPost prepared to launch.

For over two and half hours I was scratching my head to work out why the fonts weren’t rendering after we enabled production mode. I’d done everything they asked me to :

  1. Downloaded the Webfont data folder
  2. Uploaded it to S3 ( which we were accessing via CloudFront )
  3. Confirmed the fonts existed at the location.

But still no fonts.

Finding the Cause

After two and a half hours of head scratching I was able to deduce the problem was in the way that S3 was serving the files. I knew that S3 itself isn’t very clever when it comes to sending the right Content-Type header, but I’d always worked under the assumption that CloudFront would be a little more ‘intelligent’ about the Content-Type header. You know what they say about assumptions? Well they’re right; CloudFront was serving the css files with Content-Type: binary/octet. This was causing the browser to ignore them and not load their delicious font bounty,

The Fix

The fix was to to re-upload the Webfont data folder, but this time make sure to set the Content-Type header at the point of upload. I use Transmit as a browser for S3 so for me it meant a trip into the preferences to set this up:

Setting the content type for an S3 upload

You don’t need to use Transmit to do this, you could alway use the AWS S3 console.

Hope that helps you preserve some precious life.