@ font-face EOT не загружается по HTTPS

Question

Сводка

Я столкнулся с проблемой использования @ font-face поверх HTTPS в IE 7,8,9 - он просто не загружается.Не имеет значения, размещена ли содержащая HTML-страница на HTTPS или нет, , когда я пытаюсь загрузить шрифт EOT через HTTP, он работает, HTTPS - не .Кто-нибудь видел такое поведение?

Сервер, на котором размещен шрифт, отправляет правильный контент-тип = "application / vnd.ms-fontobject"

Я пробовал несколько шрифтов, поэтому он не относится к шрифту.

Шрифты были сгенерированы в Font Squirrel

Синтаксис CSS

@font-face {
font-family: 'GothamCondensedBold';
src:url('path/to/fontgothmbcd-webfont.eot');
src:url('path/to/fontgothmbcd-webfont.eot?#iefix') format('embedded-opentype'),
    url('path/to/fontgothmbcd-webfont.woff') format('woff'),
    url('path/to/fontgothmbcd-webfont.ttf') format('truetype'),
    url('path/to/fontgothmbcd-webfont.svg#GothamCondensedBold') format('svg');
font-weight: normal;
font-style: normal;
}

Пример страницы

http://gregnettles.net/dev/font-face-test.html

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

Это ошибка в IE <= 8, как прокомментировано.Вы можете увидеть некоторую информацию о проблеме здесь <a href="https://communities.bmc.com/thread/88899" rel="nofollow noreferrer">https://communities.bmc.com/thread/88899. В основном проблема заключается в загрузке файла в IE через https с Cache: заголовки no-cache установлены, попробуйте удалить заголовки кэша, чтобы увидеть, если это ваша проблема.1005 *

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

Answer 4

Хорошо, насколько я могу судить, это ошибка 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>

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

Answer 5

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

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

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

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.

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

Answer 6

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

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

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

Обе версии IE на Win 7. Я не видел проблемы на Win 8 или Win 10.

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

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

Answer 7

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