Ответ 1

Я знаю, что это старый поток, но мне просто пришлось взвесить. У нас была такая же проблема с шрифтами EOT и WOFF во всех версиях Internet Explorer (7-11), которые не загружались по HTTPS. После нескольких часов проб и ошибок и сравнения наших заголовков с другими рабочими сайтами мы обнаружили, что заголовок vary был запутанным. Сброс этого заголовка для этих типов файлов сразу устраняет проблему.

<FilesMatch "\.(woff)$">
    Header unset Vary
</FilesMatch>

<FilesMatch "\.(eot)$">
    Header unset Vary
</FilesMatch>

Ответ 2

Я столкнулся с этой проблемой с HTTPS, но не с HTTP. По какой-то причине IE продолжил бы через различные параметры шрифта, игнорируя ответы 200 OK.

В моем случае проблема заключалась в HTTP-заголовке Cache-Control: no-cache для шрифта. Хотя это будет хорошо работать с HTTP, более HTTPS заставляет Internet Explorer игнорировать загруженный шрифт.

Мое лучшее предположение заключается в том, что это вариация этого поведения: http://support.microsoft.com/kb/815313

Итак, если вы видите, что IE работает через каждый шрифт в сетевом представлении Developer Tools, возможно, стоит проверить, есть ли заголовок Cache-Control и его удаление.

Ответ 3

Это обычно происходит из-за следующих заголовков ответов при загрузке файлов .woff или .eot.

• Cache-Control = no-cache, no-store, max-age = 0, must-revalidate
• Pragma = no-cache

В моем случае я использую spring -boot и для удаления этого заголовка мне нужно было сделать следующее. который также решил проблему.

public class SecurityConfig extends WebSecurityConfigurerAdapter { 
@Override
public void configure(HttpSecurity http) throws Exception {
   http.headers().defaultsDisabled()
        .addHeaderWriter(new StaticHeadersWriter("Cache-Control"," no-cache,max-age=0, must-revalidate"))
        .addHeaderWriter(new StaticHeadersWriter("Expires","0"));
 }
}

Ответ 4

Кажется, что некоторые версии IE не могут использовать шрифт @fontface, размещенный вне домена сайта (если страница находится в http://a.domain.tld/page.html - шрифт также должен быть в http://a.domain.tld/) по той или иной причине. Поместите файл EOT в свой домен и повторите попытку, возможно.

IE9 блокирует загрузку кросс-оригинального веб-шрифта

Ответ 5

Без заголовков кеша я заметил, что клиенты IE9 в Windows Vista по-прежнему не загружают шрифты (хотя на моей новой машине разработки IE11 в режиме эмуляции IE9 это делает).

Мне удалось исправить проблему на клиентских компьютерах в Internet Explorer, перейдя к:

• Свойства обозревателя
• Дополнительно
• Безопасность

И снимите флажок "Не сохранять зашифрованные страницы на диск".

НТН

Ответ 6

Рабочее решение для Apache/2.2.15 - это добавить .htaccess

<FilesMatch "\.(woff)$">
    Header unset Cache-control
</FilesMatch>

<FilesMatch "\.(eot)$">
    Header unset Cache-control
</FilesMatch>

Ответ 7

Вот мое исправление:

Использование URL Rewrite Addon для IIS для установки заголовка Cache-Control для всех файлов EOT:

<system.webServer>
....
<rewrite>
  <outboundRules>
    <rule name="Fix IE9 missing font icons">
      <match serverVariable="RESPONSE_Cache_Control" pattern=".*" />
      <conditions>
          <add input="{REQUEST_URI}" pattern="\.eot.*" />
      </conditions>
      <action type="Rewrite" value="private, max-age=36000" />
    </rule>
  </outboundRules>
</rewrite>
</system.webServer>

Ответ 8

Вы пытались напрямую загрузить файл EOT через https? Сертификат SSL кажется плохим (несоответствующим), что вполне может быть вашей проблемой.

Вы также должны убедиться, что для этих файлов настроена междоменная политика, поэтому, возможно, это не является фактором в этой проблеме, это может вызвать проблемы для некоторых браузеров.

Ответ 9

Это звучит как проблема с вашим CDN. Вы можете проверить это, изменив свой файл хоста, чтобы ваш домен домена SSL указывал на какой-либо IP-адрес вашего трафика, отличного от SSL. Если шрифт отображается, вам нужно вызвать CDN и выяснить, что делают их серверы для файлов шрифтов.

Ответ 10

Эта проблема теперь устранена добавлением следующих записей в httpd.conf или .htaccess на сервере apache.

Чтобы заставить его работать, мы изменили его с помощью FilesMatch на LocationMatch, и теперь заголовки устанавливаются отлично.

Чтобы установить правильные типы mime для файлов шрифтов, добавьте эти строки в config:

 AddType application/vnd.ms-fontobject .eot
 AddType font/truetype .ttf
 AddType font/opentype .otf
 AddType font/opentype .woff
 AddType image/svg+xml .svg .svgz

Чтобы обновить заголовки файлов шрифтов, это исправление отлично работает для рендеринга шрифтовых значков в браузерах IE.

<LocationMatch "\.(eot|otf|woff|ttf)$">
   Header unset Cache-Control
   Header unset no-store
</LocationMatch >

Ответ 11

I Столкнулся с аналогичной проблемой, но причиной этого был заголовок Vary. В моей настройке я использовал Ruby on Rails с драгоценным камнем rack-cors. Это давало файлам шрифтов заголовок Vary: Origin. Чтобы исправить это, вы можете установить заголовок на Accept-Encoding, где вы установили промежуточное ПО:

config.middleware.insert_before 0, "Rack::Cors", :debug => true, :logger => (-> { Rails.logger }) do
  allow do
    origins '*'

    resource '/cors',
      :headers => :any,
      :methods => [:post],
      :credentials => true,
      :max_age => 0

    resource '*',
      :headers => :any,
      :methods => [:get, :post, :delete, :put, :options, :head],
      :max_age => 0,
      vary: ['Accept-Encoding'] # Required or IE11 fonts will break
  end
end

Ответ 12

Попробуйте указать полный URL с https://.... Поскольку https работает медленнее из-за расширяющихся и несжимаемых файлов, есть некоторые трюки для доставки смешанного содержимого http/https, не получая предупреждение "небезопасного контента". Вы можете их искать. Никогда не нужно было использовать такие трюки.

Ответ 13

Хорошо, насколько я могу сказать, это ошибка IE8. Я создал обходное решение, которое, по крайней мере, работает на Apache - используйте mod_rewrite для принудительного HTTP-запроса для запросов, заканчивающихся на ".eot" или ".eot?". и запустите HTTPS для всех других запросов. В файле .htaccess выполните:

<IfModule mod_rewrite.c>
  RewriteEngine on

  # if HTTPS request, force to HTTP if file ends in '.eot' or '.eot?'
  RewriteCond %{SERVER_PORT} 443
  RewriteCond %{REQUEST_URI} ^.*\.eot\??$
  RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

  # if HTTP request, force to HTTPS if file does NOT end in '.eot' or '.eot?'
  RewriteCond %{SERVER_PORT} 80
  RewriteCond %{REQUEST_URI} !.*\.eot\??$
  RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

</IfModule>

Не совсем красиво, и я уверен, что он добавляет некоторые накладные расходы сервера, при выполнении сравнения строк каждый отдельный запрос, но он устраняет проблему:)

Ответ 14

Привет, я просто столкнулся с той же проблемой, и я нашел исправление, надеюсь, что это может помочь другим.

Это ошибка в IE <= 8, как прокомментировано. Вы можете увидеть некоторую информацию о проблеме здесь https://communities.bmc.com/thread/88899. В основном проблема заключается в загрузке файла в IE через https с установленными кешами кеширования кеширования, попробуйте удалить заголовки кеша, чтобы убедиться, что это ваша проблема.

Этот ответ также может помочь IE: невозможно скачать * из *. Не удалось открыть этот интернет-сайт. Запрошенный сайт либо недоступен, либо не найден

Ответ 15

Хотелось поделиться своей ситуацией и решением в надежде, что это поможет следующему человеку.

Мои шрифты доставлялись через HTTPS через Amazon CloudFront, который был настроен для обслуживания статических активов из нашего приложения, которое живет за балансировщик эластичной нагрузки.

Шрифты имели следующие заголовки:

Access-Control-Allow-Origin: *
Cache-Control: public, max-age=100000
Cache-Control: no-cache="set-cookie"

Основываясь на других ответах и ​​вещах, которые я мог найти в Интернете, я бы ожидал, что это сработает, поскольку оно устанавливает max-age и имеет правильную конфигурацию CORS. Однако IE9 по-прежнему не будет отображать шрифты.

Вопрос оказался заголовком Cache-Control: no-cache="set-cookie", который меня удивил, потому что он просто говорит, чтобы не кэшировать заголовок Set-Cookie (если я не ошибаюсь).

Мне потребовалось некоторое время, чтобы понять, откуда этот заголовок. Этот заголовок добавлялся нашим ELB, потому что мы используем липкие сеансы с помощью файлов cookie, и я полагаю, что балансировщик нагрузки настроен на использование этого заголовка Cache-Control, когда он настроен таким образом.

Таким образом, отключение липких сеансов удалило заголовок и вызвало визуализацию шрифтов. Мы смогли отключить липкие сеансы для HTTP-запросов и оставить их для HTTPS-запросов, что прекрасно, потому что мы принудительно применяем SSL для любых нестатических активов, но с радостью обслуживаем статические активы CloudFront с использованием или без SSL.

Надеюсь, что кто-то другой найдет эту информацию полезной.

Ответ 16

Довольно старый вопрос, но я думаю, что никто не ответил правильно. Проблема в том, что шрифт был загружен из другого файла, и для меня это похоже на Access-Controll-Allow-Origin.

Он работает в значительной степени, добавляет следующее в ваш файл virtualhosts или в .htaccess:

<ifModule mod_headers.c>
    Header set Access-Control-Allow-Origin: *
</ifModule>

и перезапустите apache