@Font-Face won't load via https in IE

Question

EDIT 23-06-2012 10:24 (CET): Found the answer

Take a look at the bottom answer. That is what fixed the issue for me. IE9 is rendering the right way now. IE8 has a slightely different font. Not sure what font, but it looks "OK".

Original Question:

I've been struggling with this for several hours now. For one of our customers we've designed a webshop and been developing this over a normale unsecure http connection. Since 2 days ago, we've installed an SSL certificate on the domain and forced every connection with the website to go over the https domain using .htaccess

But, for some reason, IE (no version) renders the font we've specified in the CSS using @Font-Face. Here's on of the codes we are using for the fonts:

@font-face {
    font-family: 'ProximaNovaLight';
    src: url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.eot');
    src: url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.eot?#iefix') format('embedded-opentype'),
         url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.woff') format('woff'),
         url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.ttf') format('truetype'),
         url('https://www.bijouterieyvette.com/font-face/proximanova-light-webfont.svg#ProximaNovaLight') format('svg');
    font-weight: normal;
    font-style: normal;
}

As you can see I'm using the full link to the fonts including the https. I've tried moving the files to the root of the domain to match the SSL certificates domain. I also tried to use relative paths from within the CSS but also this didn't work.

All fonts are on the domain, none of them are cross-domain.

I came across 2 other posts here on SO describing similar problems, one of the wasn't solved, the other one was, but it didn't seem to be the same problem. In this case the author of the question had to add Access-Control-Allow-Origin headers to the file requests of woff/ttf/otf/svg. I've also added these headers to my .htaccess just to be sure:

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

I'm kind of running out of options and thoughs. I'm no server-configuration-type-of-guy, but more into PHP/MySQL/jQuery so I guess my thoughts are rather limited compared to others here on SO.

If anyone has an option which is worth trying, just let me know!

UPDATE 22-06-2012:

If I change the https to http and refresh the page in IE, I am being prompted with the message that there is non-secure content and I have the option to accept this content. If I choose 'YES' my content is being loaded and... the font is available!! Yay.. However.. if I change it back to https the fonts disappear again.

Not sure what I can learn from this (lol), but maybe this gives anyone a little idea..

UPDATE 22-06-2012 #2:

Thus far I have tried:

url('//protocol/relative/font.eot'); url('../file/relative/font.eot'); url('/domain/relative/font.eot'); url('https://www.secure.tld/font.eot'); url('http://www.normal.tld/font.eot'); (works but with a popup "Containing non secure items in IE)

I also tried to create a rewriterule forcing the FilesMatch (woff, ttf, otf, eot, svg) to a http:// connection. That didn't work as I thought and I haven't got a clue wether it did anything at all..

I also added this:

AddType application/vnd.ms-fontobject .eot
AddType font/truetype .ttf
AddType font/opentype .otf
AddType font/opentype .woff
AddType image/svg+xml .svg .svgz

To the folder containing the fonts (in an .htaccess files ofcourse) aswell as in the main .htaccess file.

Besides that I tried to remove the htpasswd login, it was a wild guess, but didn't change a thing either.

UPDATE 23-06-2012:

Checked the DirectAdmin server logs.. apparently IE is requesting the fonts (I see an eot file with the questionmark, I'm guessing this is the eot with iefix and woff being requested). Everything that's requested is also getting a 200 OK header response, which isn't making things more clear for me..

Still looking and searching for what could cause this problem..

Also, based on the "F12 Console Log"-thingy in IE. I can clearly see that the fonts are being requested -over https- with a 200 OK response. Strange thing is I only see 3 out of the 4 fonts I'm using, but possible the 4th isn't being used on the mainpage.

Solution 1

So, I just figured out a way that is working for IE, Safara, Firefox and Chrome as far as I can see.

Since all the things I tried did not work out, I was trying to find a way that could "embed" the fonts eitherway to my websites, to my CSS or to my server. Added the font to my server wasn't an option according to my server-guy so I decided to get back to Font-Squirrel and see if there was an option they offered in converting the fonts.

I reuploaded my fonts en chose the export mode. Somewhere around the bottom of the settings fields it says "Base64 Encode", luckily I knew what this meant (I can imagine someone who doesn't easily looks over this option) so I genereted my CSS files with base64 embdedded fonts.

This works flawlessly. Ofcourse this made my CSS files some kb's bigger (5kb vs 129kb). But I don't see a big adventage of 100kb extra with the current internet connections.

Just to compare, non base64 encoded CSS:

@font-face {
    font-family: 'ProximaNovaSemibolds';
    src: url('../font-face/proximanova-semibold-webfont.eot');
    src: url('../font-face/proximanova-semibold-webfont.eot?#iefix') format('embedded-opentype'),
         url('../font-face/proximanova-semibold-webfont.woff') format('woff'),
         url('../font-face/proximanova-semibold-webfont.ttf') format('truetype'),
         url('../font-face/proximanova-semibold-webfont.svg#ProximaNovaSemibold') format('svg');
    font-weight: normal;
    font-style: normal;
}

Base64 encoded CSS:

@font-face {
    font-family: 'ProximaNovaBold';
    src: url('proximanova-bold-webfont-webfont.eot');
    }

@font-face {
    font-family: 'ProximaNovaBold';
    src: url(data:application/x-font-woff;charset=utf-8;base64,d09GRgABAAAAAF+8ABMAAAAArzAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABGRlRNAAABqAAAABwAAAAcYT+YZ0dERUYAAAHEAAAALQAAADIC+wHsR1BPUwAAAfQAAAf7AAAURoqljoZHU1VCAAAJ8AAAACAAAAAgbJF0j09TLzIAAAoQAAAAWwAAAGB+FsNBY21hcAAACmwAAAGdAAAB+uY47ZljdnQgAAAMDAAAADoAAAA..alotmorecharacters...FDmYlYoTkE8HdsTFF2cwU74AAU/lecUAAA==) format('woff'),
         url('proximanova-bold-webfont-webfont.ttf') format('truetype'),
         url('proximanova-bold-webfont-webfont.svg#ProximaNovaBold') format('svg');
    font-weight: normal;
    font-style: normal;

}

Solution 2

I had exactly the same behaviour with IE and https. IE tried to load 3 of the 4 fonts but as soon as the server delivered the resource, IE broke up and moved to the next font. Finally no font was loaded and the site looked crappy. In my case the http header "pragma=no-cache" was the thing that confused IE. After removing it from the response, everything worked smoothly. See also my blog entry which explains the trick with Wildfly and Undertow: Blog

UPDATE:

In the meantime I opened a bug at microsoft connect: https://connect.microsoft.com/IE/feedbackdetail/view/992569/font-face-not-working-with-internet-explorer-and-http-header-pragma-no-cache

If you want them to fix the problem, please vote for the bug.

Solution 3

Definitely having the same problem. A combination of IE (in our case version 11/Trident 7) Bug occurs when all condition meet:

HTTPS, no-cache header

On certain domains that are administered separately, this is not a easy problem to workaround

Solution 4

Working solution for Apache/2.2.15 is to add .htaccess Its prevents caching font files even for https

<FilesMatch "\.(woff)$">
    Header unset Cache-control
</FilesMatch>

<FilesMatch "\.(eot)$">
    Header unset Cache-control
</FilesMatch>

Solution 5

You may get it to work using the Webfont-Loader, developed by Google and Typkit:

It add some overhead, but gives you also more control over font-loading (like classes that allow you to set different styles while fonts haven't yet loaded). Perhaps it is worth a try, setup for your own css seems to be simple.

View more solutions

Comments

[RoToRa]

I can't think of anything specific, but have you tried URLs without a domain, or protocol relative URLs ?

[Joshua - Pendo]

Since the fonts wont load using my own CSS I doubt that they load using the webfont loader. However, in normale CSS I can also set up a back-up font.. I'll take a look into this anyways, you'll never know. Thanks

[Rob W]

Use application/font-woff, or you will get Resource interpreted as Font but transferred with MIME type application/x-font-woff warnings.

[echen]

one possible way to work around the issue is to serve the font files from a CDN

[Nguyen Van Vinh]

Thanks you! I was lost much time for this issue. You are saved my time! To fix, i configured in .htaccess as Header set Cache-Control "max-age=604800, public". Header set Pragma ""

[user1767316]

Yes, I could overcome the problem using nginx proxy to hide pragma and cache-control headers that are generated by spring-boot that prevent caching in the browser:link

[user1767316]

[link](Using nginx): hiding both Cache-control and Pragma: no-cache

[Thijs van Dien]

This answer deserves a lot more attention. Thanks for saving me a ton of time!