WOFF files and Azure: the 404 conundrum

More than anything, this is going to be a discussion about testing, but the headline is all. 

Lazy tester

This afternoon, in trying to keep cool inside on this hot day, I thought I’d remove the Google Ads on this site. Frankly they were a pain in the neck to design for: they used to be a sidepanel on the right and trying to get the code to make them disappear when the browser window was too small width-wise was just annoying. Plus the ads were being loaded anyway even if they weren’t being displayed, meaning more code would have to be written to deal with that scenario, etc, etc. Since one of the better presentations I’ve given in the past was all about making your website or application faster to load, it behooved me to chuck ’em. Plus they only brought in on average $5 every month or so … but that wasn’t the real reason, right? Right? (Coughs and moves on.)

So, having done this, I thought the best way to test (in a verification sense) I’d properly removed them was to run the site in the developer tools for the browser and check the GET requests being made across the wire. I’m old school and still use FireBug, but I did also start up Chrome and its developer tools to cross-check. Either way, the ads were gone. Furthermore, the site now loads in under 2 seconds, even with no cache, which is remarkable. (Maybe GoDaddy has also put me on another, faster web server, I don’t know.)

Let’s just check my new homepage under the developer tools, I thought to myself. Let’s see the difference in load times! Less than a second. YESSSSS! But … wait! What is that 404? The CSS is trying to load a couple of WOFF files (Web Open Font Format files) and they’re both being returned as Not Found (404). Here’s the font definition for one of the fonts:

@font-face {
  font-family: 'Gentleman500';
  src: url('./../fonts/Gentleman-500-Book.eot'); /* IE9 Compat Modes */
  src: url('./../fonts/Gentleman-500-Book.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('./../fonts/Gentleman-500-Book.woff') format('woff'), /* Modern Browsers */
       url('./../fonts/Gentleman-500-Book.ttf') format('truetype'), /* Safari, Android, iOS */
       url('./../fonts/Gentleman-500-Book.svg#Gentleman500-Book') format('svg'); /* Legacy iOS */
  font-style: normal;
  font-weight: normal;
  text-rendering: optimizeLegibility;
}

On a 404 for a WOFF file, the browser then falls back to loading the TTF file instead.

Oops! This page has been up for three weeks now and I’ve only just discovered I’d forgotten to upload the proper font files? Talk about a testing failure. Except … the fonts had been uploaded, to the right folder, and were even named correctly (the next things I checked). So why was the web server – in this case, Azure – lying about the presence of the font file? 404 means “Not Found”, and not “It’s there but I’m going to pretend it isn’t”.

A quick bit of googling later, I came across this post on CodePal: WOFF files return 404 (Not Found) in Azure Web Sites. Even though the site is static, I have to have a web.config file that has at least this declaration in it:

<configuration>
    <system.webServer>
        <staticContent>
            <mimeMap fileExtension="woff" mimeType="application/font-woff" />
        </staticContent>
    </system.webServer>
</configuration> 

…so that the web server “knows” about the WOFF MIME type.

(Note: there are posts on StackOverflow that say the mimeType attribute should be x-font-woff instead, others that say you should also have a remove element [example]. This minimal web.config works fine for me though.)

After that minimal change, Azure serves up the WOFF font files just fine.

So, as I said in the beginning, although this post was ostensibly about WOFF files and Azure, in reality it’s all about the need for testing and verifying. In creating this new web page, I should have checked that everything rendered and worked correctly (which I did, going through several iterations of the CSS, tweaking away), but also that the loading and caching at the browser were working as expected. This latter part was even more important since I certainly didn’t write that @font-face declaration and hence had only the vaguest notion if or how it worked.

In short: do not assume anything. Test, test, and test again.

UPDATE (7-Aug-2016): This web.config fix applies to other web servers apart from Azure. I also had to use it for a static site hosted on GoDaddy.

  Loading links to posts on similar topics...

3 Responses

#1 Oded said...

26-Jul-15 9:58 AM

Azure has a similar issue with SVG files (so you may want to test those as well on a post that uses them).

Similar fix - just add the mime type to the web.config.

#2 julian m bucknall said...

26-Jul-15 8:27 PM

@Oded: ditto the EOT file as well; I've seen that mentioned too. Problem for me is that, although I have the declarations in the @font-face block, I no longer have access to (or even, frankly, care about) early IE versions or legacy iOS.

(Having said that, it works fine on a 2nd generation iPod Touch with iOS 4.2.1. That's as early as I can go...)

Cheers, Julian

#3 Vincent said...

02-Aug-15 6:51 PM

The safe way to do this is add first, then add this mine type.

Leave a response

Note: some MarkDown is allowed, but HTML is not. Expand to show what's available.

•  Emphasize with italics: surround word with underscores _emphasis_
•  Emphasize strongly: surround word with double-asterisks **strong**
•  Link: surround text with square brackets, url with parentheses [text](url)
•  Inline code: surround text with backticks `IEnumerable`
•  Unordered list: start each line with an asterisk, space * an item
•  Ordered list: start each line with a digit, period, space 1. an item
•  Insert code block: start each line with four spaces
•  Insert blockquote: start each line with right-angle-bracket, space > Now is the time...

Name (required) Mail (will not be published) (required) Website Response Submit

Preview of response