IE 11 “sometimes” preventing the display of “font-awesome” webfonts

Question

Some of our IE11 clients are not seeing the \"font-awesome\" webfonts in our web application. I have done extensive testing with our own IE11 instances, and also via cross b

Answer 1

If you can't enable downloadable fonts for DISA STIG security reasons try this solution that shows you how to Base 64 a font and use it as a CSS file to push the font through.

Answer 2

Removing the Pragma Header from the response header in the endpoint from where the fonts are downloaded solved for me.

if (request.getServletPath().contains(".woff") || request.getServletPath().contains(".ttf")) {
    headers.remove(HttpHeaders.PRAGMA);
}

Answer 3

• Cog
• Internet options
• Security
• Custom Level
• Downloads -> Font download -> Enable.

Answer 4

In my case, I could see this issue only when using Win 10 + IE 11. Even after ensuring correct IE settings (security zone and font download enabled), the font won't render. It seems that cache headers should not be set for fonts.

We are using Spring MVC and Tomcat. Adding following code in CORS filter solved problem for me.

        if (!request.getServletPath().endsWith(".woff")
                && !request.getServletPath().endsWith(".ttf")) {
            response.setHeader("Cache-Control", "no-cache");
            response.setHeader("Pragma", "no-cache");
            response.setDateHeader("Expires", -1);
        }

https://stackoverflow.com/a/33508291/828062

Answer 5

IE Security Settings

I have noticed sites in the "Restricted Sites" (in Internet Explorer) do not show font awesome whereas sites in "trusted sites" zone do.

So I'd guess the issue is with different IE security settings for different users.

Can you ask users to check / change their options in IE e.g. (instruction for IE 11 but others will be very similar) :

• Settings Cog (icon in top right)
• Internet Options (menu option)
• Security (tab)
• Sites (button)
• Enter the website address for your site
• Click Add (button)

N.B. if you are not using https you may also need the option

• "Require server verification (https:) for all sites in this zone" - to be deselected

Request a User makes these changes and then troubleshoot from there.

Fiddler to debug

If you have access to any of the user's machines, can remote in, or have any advanced users you can guide then could also attempt to debug using the excellent Fiddler http proxy on their machine to see what is happening at the http request / response level.

You can also change your own IE security settings to see if you can replicate the problem