5

I have an application employing FontAwesome's glyph fonts for icons, and everything works fine when I host the files from my server. When I enable CDN support on my site, IE 11 behaves rather strangely in regards to the font files. When navigating to a page either via clicking a link or manually entering a URL, the font files load fine ~95% of the time. If I reload a page or use forward/back buttons (or the ~5% of the time a normal page load doesn't work), IE 11 loads the first font file, loses/drops/ignores the contents of the response body somehow, tries to load the second file, loses the contents of the response body, wash-rinse-repeat, and I end up with no font glyphs. All other browsers (including older versions of IE) work fine.

@font-face declaration in CSS:

@font-face {
    font-family: 'FontAwesome';
    src: url('/common/fonts/fontawesome-webfont.eot');
    src: url('/common/fonts/fontawesome-webfont.eot?#iefix') format('embedded-opentype'),
        url('/common/fonts/fontawesome-webfont.woff') format('woff'),
        url('/common/fonts/fontawesome-webfont.ttf') format('truetype'),
        url('/common/fonts/fontawesome-webfont.svg#fontawesomeregular') format('svg');
    font-weight: normal;
    font-style: normal;
}

Normal page load:

Summary:

URL                                     Protocol  Method  Result  Type                      Received  Taken   Initiator   Wait  Start  Request  Response‎‎  Cache read‎‎  Gap‎‎
/common/fonts/fontawesome-webfont.eot   HTTPS     GET     200     application/octet-stream  99.78 KB  109 ms  @font-face  2449  0      47       62        0           1420

Response header:

Key                            Value
Response                       HTTP/1.1 200 OK
Content-Type                   application/octet-stream
Last-Modified                  Mon, 04 Aug 2014 12:49:48 GMT
Accept-Ranges                  bytes
ETag                           "07ef492e2afcf1:0"
Server                         Microsoft-IIS/7.5
P3P                            CP="NON DSP COR ADM DEV PSA IVA CONi TELi OUR BUS NAV"
Access-Control-Allow-Origin    *
Content-Length                 101712
Expires                        Mon, 15 Sep 2014 18:48:40 GMT
Cache-Control                  max-age=0, no-cache, no-store
Pragma                         no-cache
Date                           Mon, 15 Sep 2014 18:48:40 GMT
Connection                     keep-alive

Response body contains font file.

On page reload:

Summary:

URL                                     Protocol  Method  Result  Type                      Received  Taken  Initiator   Wait  Start  Request  Response‎‎  Cache read‎‎  Gap‎‎
/common/fonts/fontawesome-webfont.eot   HTTPS     GET     200     application/octet-stream  462 B     47 ms  @font-face  983   0      47       0         0           1248
/common/fonts/fontawesome-webfont.woff  HTTPS     GET     200     application/x-font-woff   461 B     63 ms  @font-face  1092  0      63       0         0           1123
/common/fonts/fontawesome-webfont.ttf   HTTPS     GET     200     application/octet-stream  462 B     93 ms  @font-face  1155  15     78       0         0           1030

Response header (for "fontawesome-webfont.eot", the others look the same, except for differences in content-length, accounting for the differences in file size):

Key                            Value
Response                       HTTP/1.1 200 OK
Content-Type                   application/octet-stream
Last-Modified                  Mon, 04 Aug 2014 12:49:48 GMT
Accept-Ranges                  bytes
ETag                           "07ef492e2afcf1:0"
Server                         Microsoft-IIS/7.5
P3P                            CP="NON DSP COR ADM DEV PSA IVA CONi TELi OUR BUS NAV"
Access-Control-Allow-Origin    *
Content-Length                 101712
Expires                        Mon, 15 Sep 2014 19:05:13 GMT
Cache-Control                  max-age=0, no-cache, no-store
Pragma                         no-cache
Date                           Mon, 15 Sep 2014 19:05:13 GMT
Connection                     keep-alive

Response body is empty. Note that content length in the details does not match the "received" value in the summary.

According to CDN logs and tracking traffic locally in Fiddler2, the full font files are being served up by the CDN. As near as I can tell, the response from the CDN is identical to the response from my server.

Enabling caching seems to eliminate the effect (at least, I have not been able to reproduce it with caching enabled), but the Powers That Be are concerned that this will affect other, non-cacheable, assets in the application as more are transitioned over to the CDN, and thus I must find the root cause and fix it rather than slap a band-aid on it.

Why might IE 11 behave as if the responses have empty response bodies? Why might IE 11 treat a response from a CDN differently from a response from the app server, if the files and response headers are the same?

asgallant
  • 26,060
  • 6
  • 72
  • 87

4 Answers4

8

I have been seeing similar issue with the CDN. Am going to update the answer if I find any other solution. IE has an issue if your font files have no cache set.

I hope this link helps.

On IE CSS font-face works only when navigating through inner links

Update : The issue fixed for me after setting the correct cache control in .htaccess file

I made mine for max-age= 3600 but max-age=0 would work too

<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
Header set Cache-Control "max-age=3600"
</IfModule>
</FilesMatch>
Community
  • 1
  • 1
animesh manglik
  • 755
  • 7
  • 14
1

MIME types are very important in IE11. You must ensure that the proper MIME types are sent for font files:

  • application/vnd.ms-fontobject for EOT fonts
  • application/font-woff for WOFF fonts

What CDN are you using? With the official FontAwesome CDN (http://www.bootstrapcdn.com/#fontawesome_tab), everything should work fine.

CedX
  • 3,854
  • 2
  • 36
  • 45
1

For anyone else finding this with the same issue, the following is info, not necessarily a solution.

IE apparently has a bug titled:

@font-face not working with Internet Explorer and HTTP-Header Pragma=no-cache

They have closed the bug as Won't Fix.

View details here: http://connect.microsoft.com/IE/feedbackdetail/view/992569/font-face-not-working-with-internet-explorer-and-http-header-pragma-no-cache

I noticed the same issue immediately after adding a few headers to prevent caching, including the pragma header.

Seth Flowers
  • 8,990
  • 2
  • 29
  • 42
0

So I don't have a good explanantion for why this is failing, but the solution that the one that works, not the one that is ideal. You can burn a good deal of time trying to troubleshoot this and still not get anywhere, there are a ton of variables involved.

Can you set the font fallback to hit your server as opposed to the cdn?

You should be able to specify it in the css that you use one font face, and then another if it fails.

   body { font-family:"FontAwesome", "FontAwesomeFallback"; }

Make the FontAwesomeFallback point to your local directory and see if IE11 has the same issue. If it's a CDN issue, hitting your local directories shouldn't be an issue and the font will render properly. If it still fails, it may be an issue with the fontface itself.

jorblume
  • 607
  • 6
  • 19