Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Firefox won't load @font-face from another domain

M

Makosuke

macrumors 604
Original poster
Aug 15, 2001
6,812
1,539
The Cool Part of CA, USA
This is less a question than a note for reference, in hopes that if someone else searches for the same problem I just spent an hour and a half banging my head against, they'll find it. Someone else has no doubt documented it somewhere, but my Googling completely failed to help.

Upshot is I had a nice, simple @font-face implementation working well.

Then, along the line somewhere, I decided to move the font files to my media subdomain; as per some Yahoo recommendations, the media subdomain is at a different domain, so that cookies set for the main site content don't get fed along with all the requests to the media domain, since they're of no use there. Yes, it's a vanishingly small speed increase, but why not.

Well, when I went to do final verification, all my @font-face rules had stopped working in Firefox (and Opera, I'm assuming for the same reason, though I haven't tested yet). Safari and IE both fine. Huh?

A ridiculous number of experiments later and I finally figured out it has to do with the new implementation of HTTP access control.

Upshot, as much as I can be bothered to read at 4:30am after an hour and a half of frustration, is that FF3.5 institutes some new HTTP header stuff wherein resources from a different domain will only be loaded if the HTTP headers specifically allow that particular cross-domain pairing.

One of its intended effects, listed right at the top of the document, it to only allow font resources to be loaded from sites with explicit permission to do so.

Which, being that it is not (so far as I've found) particularly widely documented, means that if you try to load a font from a domain other than the requesting one, it won't work, for no apparent reason whatsoever, and there are no errors reported in the FF console that I could find. Setting up the HTTP headers correctly is one workaround; the other is just sticking the fonts on the same domain.

MAN that was frustrating. I'm sure there's a very legitimate and valid reason for doing this, but I suddenly hate FireFox so much more than I did yesterday. I'm sure it'll pass.
 
Nice find. This is one of the issues with working with the latest and greatest techniques. Always harder to find solutions.

As far as solutions, you mention setting up the HTTP headers correctly. I looked at the link and a few other pages and while I get what header piece is needed, I'm not sure where you're suppose to do the setting up. The linked page shows some stuff with JavaScript, but @font-face is done with CSS. I also found this page for PHP, but that still doesn't tell me how to set things up for a font file. I'd guess you may be able to do something with the .htaccess file, but not sure on the specifics. Any ideas, or did you just move the files to your domain?

I'm sure the reasoning for doing this (Firefox) was a security one. A List Apart's latest article was about web fonts and the new stuff coming out. It talks about licensing issues and protecting fonts. While this cross-domain block would not stop people from stealing a font, it would keep others from hot-linking the fonts. It could also give a way to block a potential attack vector if a vulnerability is found.
 
angelwatt said:
I'd guess you may be able to do something with the .htaccess file, but not sure on the specifics. Any ideas, or did you just move the files to your domain?
Click to expand...
I've never used PHP to mess with response headers (though I was under the impression it's possible), so I figured .htaccess as well. I haven't actually done it, though, as that article wasn't really designed as a "how to" so much as "why"; I may sit down later when I'm better rested and try to figure out exactly what needs to go in the .htaccess file to add the appropriate headers.

Given the existing means of anti-hotlink protection available, it seems a little like overkill to add another layer of complexity to something one would sort of expect to be a straightforward process, but then I'm neither a security nor rights-management expert.
 
For anyone else that finds this via Google search, here's the quick fix using an .htaccess file and the mod_headers module. No idea if the mod_headers is a fairly standard module, or if I just got lucky on my server :p

Create and upload a file named .htaccess to the directory containing your fonts, with the following contents:

Code: 
<Files ~ "\.(ttf|woff)$">
	Header add Access-Control-Allow-Origin "*"
</Files>

This will automatically add the required header to every file served from that directory. The asterisk denotes the ability for any server to access this file... If you want to be picky and only let pages from specific servers load these fonts, change the "*" to "http://myserver.com". Not sure what to do if you need to serve to multiple servers... Mozilla's page was less than specific. It might be comma-separated, it might require multiple headers.

If this fix won't work for you, try going the PHP route to add headers. I could write up something if someone needs, but it just gets messy. This is the clean/preferred solution afaik.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back