@ font-face EOT no se carga a través de HTTPS

Resumen

Me encuentro con un problema al utilizar @ font-face a través de HTTPS en IE 7,8,9; simplemente no se está cargando. No importa si la página HTML que contiene está alojada en HTTPS o no, cuando bash cargar la fuente EOT sobre HTTP funciona, HTTPS no . ¿Alguien ha visto este comportamiento?

El servidor que aloja la fuente está enviando el tipo de contenido adecuado = “application / vnd.ms-fontobject”

He intentado varias fonts, por lo que no es específico de la fuente.

Las fonts se generaron en Font Squirrel

Sintaxis 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; } 

Página de Ejemplo

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

Sé que este es un hilo antiguo, pero tuve que sopesarlo. Tuvimos el mismo problema con las fonts EOT y WOFF en todas las versiones de Internet Explorer (7-11) que no se cargaban a través de HTTPS. Después de horas de prueba y error y de comparar nuestros encabezados con otros sitios de trabajo, descubrimos que era el encabezado de vary que estaba estropeando las cosas. Inhabilitar ese encabezado para esos tipos de archivos solucionó nuestro problema de inmediato.

  Header unset Vary   Header unset Vary  

Lectura de bonificación

  • Eric Lawrence: Varía con cuidado ( archivo )
  • IE Blog: Mejoras de almacenamiento en caché en Internet Explorer 9 ( archivo )

Me encontré con este problema con HTTPS, pero no con HTTP. Por alguna razón, IE continuaría a través de las diferentes opciones de fuente, ignorando 200 OK respuestas 200 OK .

En mi caso, el problema era el encabezado HTTP Cache-Control: no-cache para la fuente. Si bien esto funcionará bien con HTTP, a través de HTTPS hace que Internet Explorer ignore la fuente descargada.

Mi mejor suposición es que es una variación de este comportamiento:

KB 815313 – Evite el almacenamiento en caché al descargar documentos activos a través de SSL ( archivo )

Por lo tanto, si ve que IE funciona a través de cada fuente en la vista de red de Developer Tools, podría valer la pena verificar si tiene un encabezado de Cache-Control y eliminarlo.

Esto generalmente ocurre debido a los siguientes encabezados de respuesta al descargar los archivos .woff o .eot.

  • Cache-Control = no-cache, no-store, max-age = 0, debe-revalidar
  • Pragma = no-caché

En mi caso estoy usando Spring-boot y para eliminar estos encabezados tenía que hacer lo siguiente. que resolvió el problema también.

 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")); } } 

Aquí está mi solución:

Uso del complemento Reescribir URL para IIS para establecer Cache-Control encabezado de Cache-Control para todos los archivos EOT:

  ....             

Sin los encabezados de caché, he notado que los clientes de IE9 en Windows Vista todavía no cargan las fonts (aunque en mi máquina de desarrollo más reciente IE11 en modo de emulación IE9 lo hace).

Pude solucionar el problema en las máquinas del cliente, en Internet Explorer, yendo a:

  • opciones de Internet
  • Avanzado
  • Seguridad

Y desmarque la opción ” No guardar páginas encriptadas en el disco “.

Lectura de bonificación

  • Eric Lawrence: Evite “No guardes las páginas encriptadas en el disco” ( archivo )

HTH

Me parece recordar que ciertas versiones de IE no pueden usar una fuente @fontface alojada fuera del dominio del sitio (si la página está en http: // un.domain.tld / page.html) , la fuente también debe estar en http: // a .domain.tld / ) por una razón u otra. Coloque el archivo EOT en su dominio y vuelva a intentarlo tal vez.

IE9 bloquea la descarga de fuente web de origen cruzado

La solución de trabajo para Apache / 2.2.15 es agregar .htaccess

  Header unset Cache-control   Header unset Cache-control  

Este problema ahora se resolvió agregando las siguientes entradas a httpd.conf o .htaccess en el servidor apache.

Para que funcione, hemos cambiado el uso de FilesMatch a LocationMatch y ahora los encabezados se están configurando perfectamente.

Para establecer tipos de mime correctos para los archivos de fonts, agregue estas líneas a 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 

Para actualizar los encabezados de los archivos de fonts, esta solución funcionó perfectamente para representar icons de fonts en los navegadores IE.

  Header unset Cache-Control Header unset no-store  

¿Intentó descargar directamente el archivo EOT sobre https? El certificado SSL parece ser malo (no coincidente), lo que bien podría ser su problema.

También debe asegurarse de que haya una política de dominio cruzado configurada para esos archivos, por lo que, aunque puede no ser un factor en este tema, podría causar problemas para ciertos navegadores.

Esto suena como un problema con su CDN. Puede verificar esto al cambiar su archivo de host para que su dominio SSL apunte a la IP a la que se atiende su tráfico no SSL. Si la fuente rinde, tendrá que llamar a su CDN y averiguar qué están haciendo sus servidores con los archivos de fonts.

Me enfrenté a un problema similar, pero fue el encabezado Vary el culpable. En mi configuración, estaba usando Ruby on Rails con la gem rack-cors . Daba a los archivos de fonts un encabezado de Vary: Origin . Para solucionarlo, puede configurar el encabezado para Accept-Encoding donde configuró el middleware:

 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 

Pruebe las URL completas con https: // …. Como https es más lento debido a los archivos de ampliación y no comprimibles, existen algunos trucos para entregar contenido mixto http / https, sin obtener una advertencia de “contenido inseguro”. Puede buscarlos. Nunca necesité usar tales trucos.

Ok, en lo que puedo decir, este es un error de IE8. Creé una solución alternativa que al menos funciona en Apache: use mod_rewrite para forzar HTTP para las solicitudes que terminan en ‘.eot’ o ‘.eot?’ y forzar HTTPS para todas las demás solicitudes. En su archivo .htaccess, haga:

  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]  

No es exactamente bonito y estoy seguro de que agrega un poco de sobrecarga del servidor, ejecutando la comparación de cadenas en cada solicitud, pero soluciona el problema 🙂

Hola, me encontré con el mismo problema y encontré una solución, espero que esto pueda ayudar a otros.

Es un error en IE <= 8 como se comentó. Puede ver información sobre el problema aquí https://communities.bmc.com/thread/88899 . Básicamente, el problema es descargar un archivo en IE sobre https con caché: no se configuran los encabezados de caché, intente eliminar los encabezados de caché para ver si ese es su problema.

Esta respuesta también puede ayudar a IE: no se puede descargar * desde *. No se puede abrir este sitio de Internet. El sitio solicitado no está disponible o no se puede encontrar

Quería compartir mi situación y solución con la esperanza de que ayude a la siguiente persona.

Mis fonts se entregan a través de HTTPS a través de Amazon CloudFront , que se configuró para servir a los activos estáticos de nuestra aplicación que se encuentra detrás de Elastic Load Balancer .

Las fonts tienen los siguientes encabezados:

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

Con base en otras respuestas y cosas que pude encontrar en Internet, esperaba que esto funcionara, ya que estaba configurando un max-age y tenía la configuración de CORS adecuada. Sin embargo, IE9 todavía no renderizaría las fonts.

El problema resultó ser el encabezado Cache-Control: no-cache="set-cookie" , que me sorprendió porque eso solo indica no almacenar en caché el encabezado Set-Cookie (a menos que esté equivocado).

Me tomó un tiempo averiguar de dónde venía ese encabezado. Este encabezado fue agregado por nuestro ELB porque estamos usando sesiones adhesivas a través de cookies, y creo que el balanceador de carga está configurado para usar este encabezado Cache-Control cuando está configurado de esa manera.

Así que al desactivar las sesiones adhesivas, se eliminó el encabezado y se generaron las fonts. Pudimos desactivar las sesiones adhesivas para las solicitudes HTTP y dejarlas activadas para las solicitudes HTTPS, lo cual está bien porque forzamos a SSL para cualquier activo no estático, pero servimos felizmente los activos estáticos a CloudFront con o sin SSL.

Espero que alguien más pueda encontrar útil esta información.

Muy vieja pregunta, pero creo que nadie respondió correctamente. El problema es que la fuente se ha cargado desde otro archivo y para mí esto parece ser un caso para Access-Controll-Allow-Origin.

Está funcionando bastante adelante añade lo siguiente en tu archivo de hosts virtuales o en .htaccess:

  Header set Access-Control-Allow-Origin: *  

y reinicia el apache

El uso de la fuente web con IE 11 sobre HTTPS puede ser un problema al usar HTTP funciona bien.

Solo hay una versión específica de IE 11 afectada , por ejemplo

  • Versión 11.0.9600.19035, versión de actualización 11.0.65
  • Versión 11.0.9600.17728, actualización de la versión 11.0.18.

Ambos son IEs en Win 7. No he visto el problema en Win 8 o Win 10.

A pesar de que Google afirma que es compatible con Microsoft Internet Explorer versión 6+, sus fonts se ven afectadas de la misma manera que se describió anteriormente.

Actualmente no conozco ninguna solución, ni siquiera una forma de detectar las versiones afectadas a través de HTML / CSS / JavaScript.