IE 11无法加载资源文件 [英] IE 11 fails to load resource files
问题描述
我有一个应用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?
推荐答案
我一直在CDN上看到类似的问题。如果我找到其他解决方案，将更新答案。
如果您的字体文件未设置缓存，则IE会出现问题。
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.
更新：在.htaccess文件中设置正确的缓存控件后，该问题为我解决了
Update : The issue fixed for me after setting the correct cache control in .htaccess file
我以max-age = 3600开采了我，但max-age = 0也可以工作
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>
这篇关于IE 11无法加载资源文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
