Summary

I'm running into an issue using @font-face over HTTPS in IE 7,8,9 - it simply is not loading. It does not matter whether the containing HTML page is hosted on HTTPS or not, when I try to load the EOT font over HTTP it works, HTTPS it doesn't. Has anyone seen this behavior?

The server hosting the font is sending the proper content-type="application/vnd.ms-fontobject"

I've tried multiple fonts, so it's not specific to the font.

The fonts were generated over at Font Squirrel

CSS Syntax

@font-face {
font-family: 'GothamCondensedBold';
src:url('path/to/fontgothmbcd-webfont.eot');
src:url('path/to/fontgothmbcd-webfont.eot?#iefix') format('embedded-opentype'),
    url('path/to/fontgothmbcd-webfont.woff') form开发者_运维技巧at('woff'),
    url('path/to/fontgothmbcd-webfont.ttf') format('truetype'),
    url('path/to/fontgothmbcd-webfont.svg#GothamCondensedBold') format('svg');
font-weight: normal;
font-style: normal;
}

Sample Page

http://gregnettles.net/dev/font-face-test.html

I ran into this problem with HTTPS, but not HTTP. For some reason IE would continue through the different font options, ignoring 200 OK responses.

In my case, the problem was the HTTP header Cache-Control: no-cache for the font. While this will work fine with HTTP, over HTTPS it causes Internet Explorer to ignore the downloaded font.

My best guess is that it's a variation of this behaviour:

KB 815313 - Prevent caching when you download active documents over SSL (archive)

So, if you're seeing IE work through each font in the Developer Tools network view, it might be worth checking if you have a Cache-Control header and removing it.

I know this is an old thread but I just had to weigh in. We had the same issue with EOT and WOFF fonts in all versions of Internet Explorer (7-11) not loading over HTTPS. After hours of trial and error and comparing our headers with other working sites we found it was the vary header that was messing things up. Unsetting that header for those file types fixed our issue right away.

<FilesMatch "\.(woff)$">
    Header unset Vary
</FilesMatch>

<FilesMatch "\.(eot)$">
    Header unset Vary
</FilesMatch>

Bonus Reading

• Eric Lawrence: Vary with Care (archive)
• IE Blog: Caching Improvements in Internet Explorer 9 (archive)

This usually happens due to following response headers while downloading the .woff or .eot files.

• Cache-Control = no-cache, no-store, max-age=0, must-revalidate
• Pragma = no-cache

In My case I am using spring-boot and to remove these header I had to do following . which solved the issue as well.

public class SecurityConfig extends WebSecurityConfigurerAdapter { 
@Override
public void configure(HttpSecurity http) throws Exception {
   http.headers().defaultsDisabled()
        .addHeaderWriter(new StaticHeadersWriter("Cache-Control"," no-cache,max-age=0, must-revalidate"))
        .addHeaderWriter(new StaticHeadersWriter("Expires","0"));
 }
}

Here is my fix:

Using the URL Rewrite Addon for IIS to set Cache-Control header for all EOT files:

<system.webServer>
....
<rewrite>
  <outboundRules>
    <rule name="Fix IE9 missing font icons">
      <match serverVariable="RESPONSE_Cache_Control" pattern=".*" />
      <conditions>
          <add input="{REQUEST_URI}" pattern="\.eot.*" />
      </conditions>
      <action type="Rewrite" value="private, max-age=36000" />
    </rule>
  </outboundRules>
</rewrite>
</system.webServer>

Without cache headers, I have noticed that IE9 clients on Windows Vista still do not load fonts (even though on my newer development machine IE11 in IE9 emulation mode does so).

I was able to fix the issue on the client machines, in the Internet Explorer, by going to:

• Internet Options
• Advanced
• Security

And unchecking the “Do not save encrypted pages to disk” option.

Bonus Reading

• Eric Lawrence: Avoid “Do not save encrypted pages to disk” (archive)

HTH

I seem to remember certain versions of IE cannot use an @fontface font hosted outside the site's domain (If the page is at http://a.domain.tld/page.html - font must also be in the http://a.domain.tld/) for one reason or another. Put the EOT file on your domain and try again maybe.

IE9 blocks download of cross-origin web font

Working solution for Apache/2.2.15 is to add .htaccess

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

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

This issue has now been resolved by adding the following entries to the httpd.conf or .htaccess in apache server.

In order to get it to work we have changed from using FilesMatch to LocationMatch and now the headers are being set perfectly.

To set right mime-types for font files, add this lines to config:

 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 update font files headers, This fix perfectly worked to render Font Icons in IE Browsers.

<LocationMatch "\.(eot|otf|woff|ttf)$">
   Header unset Cache-Control
   Header unset no-store
</LocationMatch >

Did you try directly downloading the EOT file over https? The SSL certificate appears to be bad (mismatched), which could very well be your problem.

You should also make sure that there is a cross-domain policy set up for those files so while it may not be a factor in this issue, it could cause problems for certain browsers.

This sounds like a problem with your CDN. You can verify this by changing your host file to have your SSL domain point to whatever IP your non-SSL traffic is served over. If the font renders, you'll need to call up your CDN and figure out what their servers are doing to font files.

I Faced a similar issue, but it was the Vary header that was the culprit. In my setup I was using Ruby on Rails with the rack-cors gem. It was giving the font files a header of Vary: Origin. To fix this you can set the header to Accept-Encoding where you set up the middleware:

config.middleware.insert_before 0, "Rack::Cors", :debug => true, :logger => (-> { Rails.logger }) do
  allow do
    origins '*'

    resource '/cors',
      :headers => :any,
      :methods => [:post],
      :credentials => true,
      :max_age => 0

    resource '*',
      :headers => :any,
      :methods => [:get, :post, :delete, :put, :options, :head],
      :max_age => 0,
      vary: ['Accept-Encoding'] # Required or IE11 fonts will break
  end
end

Try full URLs with https://... . As https is slower because of the enlarging and uncompressable files, there are some tricks to deliver mixed http/https content, without getting an "insecure content" warning. You might search for them. Never needed to use such tricks.

Ok, as far as I can tell this is an IE8 bug. I created a workaround that at least works on Apache - use mod_rewrite to force HTTP for requests ending in '.eot' or '.eot?' and force HTTPS for all other requests. In your .htaccess file, do:

<IfModule mod_rewrite.c>
  RewriteEngine on

  # if HTTPS request, force to HTTP if file ends in '.eot' or '.eot?'
  RewriteCond %{SERVER_PORT} 443
  RewriteCond %{REQUEST_URI} ^.*\.eot\??$
  RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

  # if HTTP request, force to HTTPS if file does NOT end in '.eot' or '.eot?'
  RewriteCond %{SERVER_PORT} 80
  RewriteCond %{REQUEST_URI} !.*\.eot\??$
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

</IfModule>

Not exactly pretty and I'm sure it adds some server overhead, running the string comparison every single request, but it fixes the issue :)

Hi I've just run into the same problem and I've found a fix, hope this can help others.

It is a bug in IE <= 8 as commented. You can see some information on the problem here https://communities.bmc.com/thread/88899. Basically the problem is downloading a file in IE over https with Cache: no-cache headers being set, try remove the cache headers to see if that is your problem.

This answer may also help IE : Unable to download * from *. Unable to open this Internet site. The requested site is either unavailable or cannot be found

Wanted to share my situation and solution in hopes it helps the next person.

My fonts were being delivered over HTTPS via Amazon CloudFront, which was configured to serve static assets from our application that lives behind an Elastic Load Balancer.

The fonts had the following headers:

Access-Control-Allow-Origin: *
Cache-Control: public, max-age=100000
Cache-Control: no-cache="set-cookie"

Based on other answers and things I could find on the internet, I would've expected this to work, since it was setting a max-age and had proper CORS configuration. However, IE9 still would not render the fonts.

The issue turned out to be the Cache-Control: no-cache="set-cookie" header, which surprised me because that just says to not cache the Set-Cookie header (unless I'm mistaken).

It took me awhile to figure out where that header was coming from. This header was being added by our ELB because we are using sticky sessions via cookies, and I guess the load balancer is configured to use this Cache-Control header when it is setup that way.

So turning off sticky sessions removed the header, and caused the fonts to render. We were able to turn off sticky sessions for HTTP requests, and leave them on for HTTPS requests, which is fine because we force SSL for any non-static assets, but happily serve static assets to CloudFront with or without SSL.

Hope someone else can find this information useful.

Quite old question, but I think no one answered correctly. The problem is that the font has been loaded from another file and for me this seems to be a case for Access-Controll-Allow-Origin.

It's working pretty much straigth forward add the following in your virtualhosts file or in .htaccess:

<ifModule mod_headers.c>
    Header set Access-Control-Allow-Origin: *
</ifModule>

and restart the apache

Using web font with IE 11 over HTTPS can be problem while using HTTP works fine.

There are only specific version of IE 11 affected, e.g.

• Version 11.0.9600.19035, Update version 11.0.65
• Version 11.0.9600.17728, Update Version 11.0.18.

Both are IEs on Win 7. I haven't seen the problem on Win 8 or Win 10.

Even though Google states to support Microsoft Internet Explorer version 6+, their fonts are affected in the same way as described above.

Currently I know of no workaround, not even a way of detecting affected versions via HTML/CSS/JavaScript.

I was able to solve the problem with not working fonts in IE on https pages. the only working option that I found was to download a font in base64 via css

@font-face {
    font-family: 'your font name';
    src: url('data:application/font-woff2;charset=utf-8;base64,...base64FontWoff2...') format('woff2'),url('data:application/font-woff;charset=utf-8;base64,...base64FontWoff...') format('woff');
    font-weight: normal;
    font-style: normal;
    font-display: swap;
}

on this site you can prepare a css file here - https://transfonter.org/