У меня есть приложение, использующее шрифты шрифта FontAwesome для значков, и все работает отлично, когда я размещаю файлы с моего сервера. Когда я включаю поддержку CDN на своем сайте, IE 11 ведет себя довольно странно в отношении файлов шрифтов. При навигации по странице либо путем нажатия ссылки, либо вручную введите URL-адрес, файлы шрифтов загружаются штрафом ~ 95% времени. Если я перезагружаю страницу или использую кнопки вперед/назад (или ~ 5% времени, когда нормальная загрузка страницы не работает), IE 11 загружает первый файл шрифта, проигрывает/падает/игнорирует содержимое тела ответа как-то , пытается загрузить второй файл, теряет содержимое тела ответа, стирает-промыть-повторить, и в итоге у меня нет глифов шрифтов. Все остальные браузеры (включая более старые версии IE) работают нормально.IE 11 не загружает файлы ресурсов
@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 прод Файл шрифта ains.
На перезагрузки страницы:
Резюме:
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
заголовка ответа ("fontawesome-webfont.eot", другие выглядят одинаково, различия в длине содержимого, за исключением, что составляет разница в размере файла):
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
Корпус отклика пуст. Обратите внимание, что длина содержимого в деталях не соответствует «полученному» значению в сводке.
Согласно журналам CDN и отслеживанию трафика локально в Fiddler2, все файлы шрифтов подаются CDN. Насколько я могу судить, ответ CDN идентичен отклику моего сервера.
Включение кэширования, по-видимому, устраняет эффект (по крайней мере, я не смог воспроизвести его с включенным кешированием), но Powers That Be обеспокоен тем, что это повлияет на другие, не кэшируемые активы в приложении, как больше переходят на CDN, и поэтому я должен найти основную причину и исправить ее, а не надавить на нее бандажную помощь.
Почему IE 11 может вести себя так, как будто ответы имеют пустые тела ответа? Почему IE 11 может обрабатывать ответ от CDN иначе, чем ответ от сервера приложений, если файлы и заголовки ответов одинаковы?