IE9 блокирует загрузку кросс-оригинального веб-шрифта
Это сводит меня с ума.
Просто тестировав сайт в IE9 и обнаружив, что "живая" версия представляет собой веб-шрифт, который я использую меньше, чем в dev-версии.
Вот список захватов экрана:
![enter image description here]()
Я использую набор шрифтов Font Squirrel @font-face. Как вы можете видеть, это прекрасно работает в Firefox, Chrome и даже IE9 при просмотре локальной версии сайта.
Единственная разница между локальной и живой версиями заключается в том, что шрифт загружается из другого домена на реальном сайте (я правильно установил междоменную политику, о чем свидетельствует тот факт, что он работает в Firefox и Chrome).
Я не помню, как это выглядело в IE8 (Microsoft, опять же, не подумала о разработчиках и установила IE9 поверх IE8 без возможности запуска их одновременно)
Сайт находится в http://enplanner.com, чтобы вы могли просмотреть источник.
Любая помощь по этому поводу была бы очень признательна - спасибо заранее.
Изменить: Я удалил IE9 и обнаружил, что он выглядит точно так же как на локальном, так и в реальном времени в IE8. Похоже, IE8 обладает превосходным механизмом рендеринга, который ближе к FF/Chrome, чем IE9. Это довольно удручающее открытие.
Ответы
Ответ 1
IE9 поддерживает .WOFF; IE8 не поддерживает и поддерживает только .EOT-шрифты.
Откройте Инструменты разработчика IE9 F12 и вы увидите следующие сообщения:
CSS3117: @font-face failed cross-origin request. Resource access is restricted.
Neuton-webfont.woff
CSS3117: @font-face failed cross-origin request. Resource access is restricted.
YanoneKaffeesatz-Regular-webfont.woff
CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable.
Neuton-webfont.ttf
CSS3114: @font-face failed OpenType embedding permission check. Permission must be Installable.
YanoneKaffeesatz-Regular-webfont.ttf
Изучая ваши HTTP-заголовки, ясно, что ваш междоменный доступ не настроен должным образом, поскольку в ваших файлах WOFF нет заголовка ответа Access-Control-Allow-Origin
. Они также поставляются с неправильным типом MIME (text/plain
), хотя это не вызывает проблемы. Однако отказ сопоставления woff
с правильным типом MIME может вызвать проблемы, так как некоторые серверы не будут обслуживать файлы с расширениями "undefined" и вместо этого возвращают ошибку HTTP/404
.
Ответ 2
ОК, вот что сработало. Разместите следующий раздел в своей конфигурации Apache для хоста, на котором вы обслуживаете шрифты:
<FilesMatch "\.(ttf|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "http://mydomain.com"
</IfModule>
</FilesMatch>
Замените "mydomain.com" либо собственным доменом, либо *
(но будьте осторожны с помощью *
, так как это означает, что любой может использовать ваш CDN)
"Woff" был тем, что я забыл. Doh!
Ответ 3
Для IIS Добавьте строки ниже.... работает как шарм
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE,OPTIONS" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
</customHeaders>
</httpProtocol>
</system.webServer>
Ответ 4
Что касается ответа от среднего значения, я хотел бы дополнить.
У нас была та же проблема, и мы искали то, что делает Google Web Font.
Итак, мы включили наш htaccess:
Набор заголовков Access-Control-Allow-Origin "*"
вместо нашего домена.
Если asterisc, как и Google, работает все время.
Ответ 5
Я нашел одно обходное решение. Добавлено это в htaccess.
BrowserMatch MSIE best-standards-support
Header set X-UA-Compatible IE=8 env=best-standards-support
Ответ 6
Проверьте, можете ли вы открыть в IE файл (your-web.com/your-font.woff). Если вы получите ошибку 404, перейдите в IIS, дважды щелкните параметр конфигурации "MIME Types" при наличии IIS root node, выбранный на левой панели, и нажмите ссылку "Добавить..." на панели "Действия" справа. Появится следующий диалог. Добавьте расширение woff и укажите " application/x-font-woff" как соответствующий тип MIME.
Я использую эти инструкции на этом сайте (Robòtica educativa), я конвертирую свой оригинальный шрифт .ttf в (http://www.font2web.com/)
Ответ 7
Альтернативным решением для использования заголовка Access-Control-Allow-Origin является встраивание шрифта в ваш CSS с использованием данных:.
Ответ 8
Также стоит отметить, что если ваши активы размещены на Amazon AWS S3, вы не сможете установить заголовки, отправляемые сервером. Вместо этого вам нужно будет настроить параметры CORS на вашем ковше в соответствии с этими инструкциями:
Ответ 9
Не забудьте включить .svg - это может быть необходимо в некоторых случаях. Добавление его разрешило проблему в IE 11
<FilesMatch "\.(eot|otf|svg|woff|ttf)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
Ответ 10
Для реализации в ASP.Net вы можете использовать этот синтаксис
Response.AppendHeader("Access-Control-Allow-Origin", "*");
Ответ 11
Я пробовал все: от изменения конфигурации apache и файлов .htaccess без везения. В инструментах разработки IE я наткнулся на "Режим документа", и по умолчанию был IE7. Поэтому после некоторых исследований я нашел этот метатег:
<meta http-equiv="X-UA-Compatible" content="IE=9">
Теперь IE 10 и 9 правильно отформатируют мой сайт и правильно отображают все значки шрифтов Awesome.
Надеюсь, что это поможет...
Ответ 12
НЕ ИСПЫТАН!
Файл файла Nginx для разрешения доступа только к файлам шрифтов, если ваш CDN не является общедоступным:-) Счастливое кодирование
location ~ \.(ttf|otf|eot|woff)$ {
Access-Control-Allow-Origin: *
}
Ответ 13
После обнаружения этой ошибки в консоли (F12): @font-face failed cross-origin request. Resource access is restricted
Я обнаружил, что мой браузер (IE11, эмуляция: IE9) "заблокировал контент, чтобы защитить мою конфиденциальность". Разблокируя контент - щелкните знак рядом с URL-адресом - он работал так, как должен.