IE 11无法加载资源文件

我有一个应用FontAwesome的字形字体作为图标的应用程序，当我从服务器托管文件时一切正常。当我在网站上启用CDN支持时，IE 11在字体文件方面表现得很奇怪。通过单击链接或手动输入URL导航到页面时，字体文件的加载时间大约为95％。如果我重新加载页面或使用前进/后退按钮（或正常页面加载的〜5％的时间不起作用），则IE 11会加载第一个字体文件，以某种方式丢失/删除/忽略响应正文的内容，尝试加载第二个文件，丢失响应正文的内容，反复冲洗重复，最后我没有字体字形。所有其他浏览器（包括IE的较早版本）都可以正常工作。

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 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;
}

正常页面加载：

摘要：

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

响应头：

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.

页面重新加载：

摘要：

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（对于 fontawesome-webfont.eot，其他内容看起来相同，除了内容长度不同，占文件大小的差异）：

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.

根据CDN日志并在Fiddler2中本地跟踪流量，完整字体文件为由CDN提供服务。据我所知，CDN的响应与服务器的响应相同。

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.

启用缓存似乎可以消除这种影响（至少，我还没有能够在启用缓存的情况下重现它），但是担心的是，随着更多的内容过渡到CDN，这将影响应用程序中其他不可缓存的资产，因此，我必须找到根本原因并修复

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.

为什么IE 11的行为就像响应的响应主体为空？如果文件和响应标头相同，为什么IE 11会将CDN的响应与应用服务器的响应区别对待？

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?