@font-face EOT ne se charge pas sur HTTPS

Question

Résumé

Je rencontre un problème lors de l'utilisation de @font-face sur HTTPS dans IE 7, 8 et 9 - il ne se charge tout simplement pas. Peu importe que la page HTML qui le contient soit hébergée sur HTTPS ou non, Lorsque j'essaie de charger la police EOT par HTTP, cela fonctionne, mais pas par HTTPS. . Quelqu'un a-t-il constaté ce comportement ?

Le serveur qui héberge la police envoie le content-type="application/vnd.ms-fontobject" approprié.

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

Les polices ont été générées sur le site Écureuil de la police

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

Answer 1

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

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

Je pense qu'il s'agit d'une variante de ce comportement :

KB 815313 - Empêcher la mise en cache lorsque vous téléchargez des documents actifs via SSL ( archives )

Ainsi, si vous voyez IE parcourir chaque police dans la vue réseau des outils de développement, il peut être utile de vérifier si vous avez un fichier de type Cache-Control l'en-tête et le retirer.

Answer 2

Je sais que c'est un vieux fil de discussion, mais je devais juste intervenir. Nous avons eu 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 sur HTTPS. Après des heures d'essais et d'erreurs et la comparaison de nos en-têtes avec d'autres sites qui fonctionnent, nous avons trouvé que c'était le problème suivant vary la tête qui foutait le bordel. La désactivation 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 en prime

• Eric Lawrence : Varier avec prudence ( archives )
• IE Blog : Amélioration de la mise en cache dans Internet Explorer 9 ( archives )

Answer 3

Je crois me souvenir que certaines versions d'IE ne peuvent pas utiliser une police @fontface hébergée en dehors du domaine du site (si la page est à l'adresse http://a.domain.tld/page.html - doit également se trouver dans le http://a.domain.tld/ ) pour une raison ou une autre. Mettez le fichier EOT sur votre domaine et réessayez peut-être.

IE9 bloque le téléchargement d'une police web d'origine croisée

Answer 4

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

Vous devez également vous assurer qu'une politique inter-domaines a été mise en place pour ces fichiers. Bien que cela ne soit pas un facteur dans ce problème, cela pourrait causer des problèmes pour certains navigateurs.

Answer 5

Cela semble être un problème avec votre CDN. Vous pouvez le vérifier en modifiant votre fichier d'hôte pour que votre domaine SSL pointe vers l'IP sur laquelle votre trafic non-SSL est servi. Si la police est rendue, vous devrez appeler votre CDN et déterminer ce que ses serveurs font aux fichiers de police.