web-dev-qa-db-fra.com

@ font-face EOT ne se charge pas sur HTTPS

Résumé

Je rencontre un problème d'utilisation de @ font-face sur HTTPS dans IE 7,8,9 - le chargement ne s'effectue tout simplement pas. Peu importe que la page HTML contenant le fichier soit hébergée sur HTTPS ou non, lorsque je tente de charger la police EOT sur HTTP, cela fonctionne, HTTPS ne fonctionne pas. Quelqu'un at-il vu ce comportement? 

Le serveur hébergeant la police envoie le contenu approprié type-"application/vnd.ms-fontobject"

J'ai essayé plusieurs polices, donc ce n'est pas spécifique à la police.

Les polices ont été générées sur Font Squirrel

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

Page d'exemple

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

cssinternet-explorerhttpsfont-face
48
Greg

Je sais que c’est un vieux sujet, mais j’ai juste eu à peser. Nous avions le même problème avec les polices EOT et WOFF dans toutes les versions d’Internet Explorer (7-11) qui ne se chargeaient pas avec HTTPS. Après des heures d’essais et d’erreurs et en comparant nos en-têtes avec d’autres sites de travail, nous avons constaté que c’était l’en-tête vary qui dérangeait tout. La suppression de cet en-tête pour ces types de fichiers a immédiatement résolu notre problème.

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

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

Lecture Bonus

23
Chris Haas

J'ai rencontré ce problème avec HTTPS, mais pas HTTP. Pour une raison quelconque IE continuerait à travers les différentes options de police, en ignorant les réponses 200 OK.

Dans mon cas, le problème était l'en-tête HTTP Cache-Control: no-cache pour la police. Bien que cela fonctionne correctement avec HTTP, via HTTPS, Internet Explorer ignore la police téléchargée.

Ma meilleure hypothèse est qu'il s'agit d'une variante de ce comportement:

KB 815313 - Empêchez la mise en cache lorsque vous téléchargez des documents actifs sur SSL( archive )

Ainsi, si vous voyez IE manipuler chaque police de la vue réseau Outils de développement, il peut être utile de vérifier si vous avez un en-tête Cache-Control et de le supprimer.

42
tjdett

Cela se produit généralement en raison des en-têtes de réponse suivants lors du téléchargement des fichiers .woff ou .eot.

  • Cache-Control = no-cache, no-store, max-age = 0, doit être revalidé
  • Pragma = no-cache

Dans mon cas, j'utilise spring-boot et pour supprimer ces en-têtes, je devais le suivre. qui a résolu le problème aussi.

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

Voici ma solution:

Utilisation de l'URL Rewrite Addon pour IIS pour définir l'en-tête Cache-Control pour tous les fichiers 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>
4
user2173353

Sans en-têtes de cache, j'ai remarqué que les clients IE9 sur Windows Vista ne chargent toujours pas les polices (même si, sur ma nouvelle machine de développement, IE11 en mode d'émulation IE9).

J'ai pu résoudre le problème sur les ordinateurs clients, dans Internet Explorer, en allant sur:

  • Options Internet 
  • Avancée 
  • Sécurité

Désélectionnez l'option «Ne pas enregistrer les pages cryptées sur le disque».

Lecture Bonus

HTH

4
TObject

Il me semble que certaines versions de IE ne peuvent pas utiliser une police @fontface hébergée en dehors du domaine du site (si la page se trouve à l'adresse http: //a.domain.tld/page.html - font obligatoirement être dans le http: //a.domain.tld/ ) pour une raison ou une autre. Placez le fichier EOT sur votre domaine et réessayez peut-être.

IE9 bloque le téléchargement de la police Web cross-Origin

3
amcc

Ce problème a maintenant été résolu en ajoutant les entrées suivantes au fichier httpd.conf ou .htaccess du serveur Apache.

Pour que cela fonctionne, l'utilisation de FilesMatch a été remplacée par LocationMatch et les en-têtes sont maintenant parfaitement définis.

Pour définir les bons types MIME pour les fichiers de polices, ajoutez ces lignes à 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

Pour mettre à jour les en-têtes des fichiers de polices, ce correctif fonctionnait parfaitement pour rendre les icônes de police dans les navigateurs IE.

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

La solution de travail pour Apache/2.2.15 consiste à ajouter .htaccess

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

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

J'ai fait face à un problème similaire, mais c'était l'en-tête Vary qui était le coupable. Dans ma configuration, j'utilisais Ruby on Rails avec le joyau rack-cors. Cela donnait aux fichiers de polices un en-tête de Vary: Origin. Pour résoudre ce problème, vous pouvez définir l'en-tête sur Accept-Encoding où vous avez configuré le 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
1
mahi-man

Avez-vous essayé de télécharger directement le fichier EOT sur https? Le certificat SSL semble être mauvais (incompatible), ce qui pourrait très bien être votre problème.

Vous devez également vous assurer qu'une stratégie inter-domaines est définie pour ces fichiers. Ainsi, même si cela ne constitue pas un facteur important dans ce problème, certains navigateurs pourraient en souffrir.

1
ldg

Cela ressemble à un problème avec votre CDN. Vous pouvez le vérifier en modifiant le fichier de votre hôte afin que votre domaine SSL pointe sur l'adresse IP sur laquelle votre trafic non-SSL est servi. Si la police est rendue, vous devrez appeler votre CDN et comprendre ce que leurs serveurs font des fichiers de polices.

1
tterragnoj

Assez vieille question, mais je pense que personne n'a répondu correctement. Le problème est que la police a été chargée à partir d'un autre fichier et pour moi, cela semble être un cas pour Access-Controll-Allow-Origin.

Cela fonctionne assez bien en avant, ajoutez ce qui suit dans votre fichier virtualhosts ou dans .htaccess:

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

et redémarrez Apache

0
Nik Chankov

Ok, autant que je sache, il s’agit d’un bogue dans IE8. J'ai créé une solution de contournement qui fonctionne au moins sur Apache - utilisez mod_rewrite pour forcer HTTP pour les demandes se terminant par '.eot' ou '.eot?' et forcez HTTPS pour toutes les autres demandes. Dans votre fichier .htaccess, faites:

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

Pas tout à fait joli et je suis sûr que cela ajoute une surcharge au serveur, en exécutant la comparaison de chaînes à chaque demande, mais cela corrige le problème :)

0
siliconrockstar

Je voulais partager ma situation et ma solution dans l’espoir que cela aiderait la prochaine personne.

Mes polices étaient livrées viaHTTPSvia Amazon CloudFront , configuré pour gérer les actifs statiques de notre application qui se trouve derrière un Elastic Load Balancer .

Les polices avaient les en-têtes suivants:

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

Sur la base d’autres réponses et de choses que j’aurais pu trouver sur Internet, j’espérais que cela fonctionnerait, car il s'agissait de définir un max-age et de disposer de la configuration CORS appropriée. Cependant, IE9 ne rendrait toujours pas les polices.

Le problème s’est avéré être l’en-tête Cache-Control: no-cache="set-cookie", ce qui m’a surpris parce que cela dit simplement de ne pas mettre en cache l’en-tête Set-Cookie (sauf erreur de ma part).

Il m'a fallu un moment pour comprendre d'où venait cette en-tête. Cet en-tête a été ajouté par notreELBcar nous utilisons des sessions persistantes via des cookies, et je suppose que l'équilibreur de charge est configuré pour utiliser cet en-tête Cache-Control lorsqu'il est configuré de cette manière.

Désactiver les sessions persistantes a donc supprimé l'en-tête et rendu les polices. Nous avons pu désactiver les sessions persistantes pour les demandes HTTP et les laisser pour les demandes HTTPS, ce qui est correct car nous forçons SSL pour tous les actifs non statiques, mais servons heureusement les actifs statiques à CloudFront avec ou sans SSL.

J'espère que quelqu'un d'autre pourra trouver cette information utile.

0
Sean Adkinson

L'utilisation de la police Web avec IE 11 sur HTTPS peut poser un problème lorsque l'utilisation de HTTP fonctionne correctement. 

Seule seule version spécifique de IE 11 est affectée, par exemple. 

  • Version 11.0.9600.19035, mise à jour version 11.0.65
  • Version 11.0.9600.17728, mise à jour de la version 11.0.18.

Les deux sont des IE sur Win 7. Je n'ai pas vu le problème sur Win 8 ou Win 10.

Même si Google déclare prendre en charge Microsoft Internet Explorer version 6+, leurs polices sont affectées de la même manière que décrit ci-dessus.

Actuellement, je ne connais aucune solution de contournement, pas même un moyen de détecter les versions affectées via HTML/CSS/JavaScript.

0
jofeu

Salut, je viens de rencontrer le même problème et j'ai trouvé une solution, espérons que cela peut aider les autres. 

C'est un bogue dans IE <= 8 tel que commenté. Vous pouvez voir des informations sur le problème ici https://communities.bmc.com/thread/88899 . En gros, le problème est de télécharger un fichier dans IE via https avec Cache: les en-têtes sans cache étant définis, essayez de supprimer les en-têtes de cache pour voir si tel est votre problème.

Cette réponse peut également aider IE: Impossible de télécharger * à partir de *. Impossible d'ouvrir ce site Internet. Le site demandé est soit indisponible, soit introuvable.

0
brentmckendrick

Essayez des URL complètes avec https: // ... . Comme https est plus lent en raison de l’agrandissement et de la décompression des fichiers, il existe quelques astuces pour fournir un contenu http/https mixte, sans avertissement de "contenu non sécurisé". Vous pourriez les rechercher. Jamais eu besoin d'utiliser de telles astuces.

0
Joop Eggen