Way back in September ’09 Paul Irish looked at a great way to handle your @font-face definitions, asserting that the core problem with @font-face is “[IE's need for] an .eot font, and [that] other browsers must take a .ttf or .otf;” or – with Chrome and IE9 – a .woff, leaving miscellaneous mobile with .svg.
Irish noted that Richard Fink improved on this method, creating a “Mo’ Bulletproof” syntax that uses “url(//:) to prevent IE from 404‘ing on the .ttf/.otf file” as it tries to suck up the whole. damn. stack.
The precursory assumption, with all methods, is that your particular network schema is agreeable – an issue not fully addressed on StackOverflow and company. Any poor souls out there still struggling to display self-hosted fonts with @font-face may be facing similar stoppage, completely unrelated to code, as self-hosting immediately complicates planning.
This just might help.
Imagine a corporate DMZ with elaborate security policies that must maintain HIPAA compliance while serving internal and external visitors. Hosting outside your firewall isn’t an option, so you’ll need to hug it out. My advice? Give up on bulletproofing your CSS and get to know your system engineers.
The @font-face Drama:
After uploading Helvetica and Lubalin font families into SharePoint 2010 on internally-hosted hardware, our issue was thus:
- All page loads of sandbox.dmz.corporation.com hung all versions of Internet Explorer with 401, 403 or 407 errors noted in Fiddler.
- Chrome, Firefox and Safari all received the appropriate files (.woff, .otf, .ttf) and showed 200.
- SharePoint 2010‘s web front end wasn’t patched beyond October 2010.
- IIS had these MIME types:
- .EOT = application/vnd.ms-fontobject
- .WOFF = application/x-woff
- .TTF = application/octet-stream
- .OTF = font/otf
- .SVG = image/svg+xml
- All .EOT calls eventually resulted in a 503.
Baffled, we drilled in.
Eliminating Bad @font-face Syntax, SharePoint 2010, Firewalls & Proxy:
Made four requests to a simple, self-hosted web font test on an externally hosted Rackspace server.
Chrome (requesting .WOFF) and IE7 (requesting .EOT) were used to pass or fail a web font render. The first two sets of requests came from within our corporate network, the second two from a Verizon MiFi 3G network. The same laptop was used for all requests.
- Chrome downloads the font (.WOFF) successfully on either network.
- IE7 succeeds (200) in downloading the font (.EOT) on MiFi.
- IE7 fails (503) to download the font (.EOT) on our network.
For a while I was convinced that our network’s proxy was missing the .EOT MIME type and unable to pass the file, and this still seemed plausible. We’d eliminated hosting the font inside SharePoint 2010’s database as the problem; and the .EOT hang was apparently unrelated to our web front end or browser rules. User permissions on-network were a possibility, but I was really curious about other obscure stoppage in the HTTP request path. What weren’t we looking for?
After a lot of talk about character set declarations, we didn’t need to specify UTF-8 – but we were paranoid enough to check it twice.
We also engaged SharePoint gurus from the Codesigned consultancy boutique and the owner of every single machine that an HTTP request touches within our network. It took weeks, but we found the answer.
Moral of the Story – Know Your System Engineers:
Our network had an ancient security filter blocking Embedded Open Type (.EOT) fonts from downloading, hence the eventual 503 authentication error in Fiddler. The filter is part of the Intrusion Detection and Prevention System (IDPS) running on the edge of our DMZs; and because MS embedded fonts were considered a security risk back in ’09, this filter still exists on our systems – and probably a lot of others.
Our ITSEC team wanted to keep the filter in place because .EOT vulnerabilities can still be exploited on unpatched machines; and this is fine, but we needed an exception to allow .EOT traffic out from the web front end to any destination, be it inside or outside. The rationale is that we own our servers, so we know we’re not hosting exploited fonts, and our security is strong enough to discourage compromise.
Browser technology has indeed changed since the .EOT security bulletins and emergence of Bulletproof and Mo’ Bulletproof syntax, but there are plenty of oldIEs (IE7 and IE8) who still need your content. Hopefully, if you were about to give up and handle your typography with images, this will open some doors – and conversations – with your hosting team.