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

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

мое лучшее предположение, что это вариация этого поведения:

KB 815313-предотвращение кэширования при скачать активные документы через SSL (архиве)

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

обычно это происходит из-за следующих заголовков ответа при загрузке .вофф или .файлы 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"));
 }
}

вот мое решение:

используя URL-адрес переписать аддон для 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>

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

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

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

и снимите флажок"не спасают зашифрованные страницы на диск опции".

Бонус Чтение

• Эрик Лоуренс: не "не сохранять зашифрованные страницы на диск" (архиве)

HTH

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

IE9 блокирует загрузку веб-шрифта cross-origin

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

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

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

эта проблема теперь решена путем добавления следующих записей в httpd.conf or .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 >

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

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

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

Я столкнулся с подобной проблемой, но это был 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

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

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

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

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

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

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

этот ответ также может помочь IE : невозможно загрузить * от.* Не удается открыть этот узел Интернета. Узел недоступен или не найден

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

мои шрифты были доставленыHTTPS via Amazon CloudFront, который был настроен для обслуживания статических активов из нашего приложения, которое живет за Эластичный Балансировщик Нагрузки.

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

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

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

проблема оказалась , который удивил меня, потому что это просто говорит, чтобы не кэшировать Set-Cookie заголовок (если я не ошибаюсь).

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

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

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

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

он работает в значительной степени straigth вперед добавить следующее в файле virtualhosts или В.реврайт:

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

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

использование веб-шрифта с IE 11 через HTTPS может быть проблемой при использовании HTTP работает нормально.

здесь затронута только конкретная версия IE 11, например,

• версия 11.0.9600.19035, обновить версию 11.0.65
• Версия 11.0.9600.17728, Обновление Версии 11.0.18.

оба являются IEs на Win 7. Я не видел проблемы на Win 8 или Win 10.

несмотря на то, что Google поддерживает Microsoft Internet Explorer версия 6+, их шрифты влияют таким же образом, как описано выше.

В настоящее время я не знаю обходного пути, даже способа обнаружения затронутых версий через HTML/CSS/JavaScript.