IE 11 fails to load resource files - cdn

Question

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?

Answer 1

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>

Answer 2

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.

Answer 3

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.

Answer 4

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.