web-dev-qa-db-fra.com

Vous avez "Blocage du chargement de contenu actif mixte" sur le site HTTP

Problème

Je développe un site web utilisant le protocole HTTP. En développement, j'utilise Webpack avec son webpack-dev-server, qui sert la page localement sur http://localhost:9090.

J'ai été surpris de voir dans la console Firefox 58 le contenu mixte error suivant concernant le chargement du fichier de polices. C'est bizarre pour moi, car la page est servie via HTTP et non par HTTPS et je pensais que les erreurs de contenu mixte se limitaient aux pages HTTPS.

`Blocked loading mixed active content “http://localhost:9090/b1aa06d82e70bbd5a14259a94c9bbb40.ttf”

J'ai découvert que la source de l'erreur est une vidéo YouTube intégrée dans un <iframe> sur la page (<iframe src="https://www.youtube.com/embed/...>). Dès que je supprime l’incorporation de YouTube, l’erreur disparaît de la console.

Je ne comprends pas ce comportement, car ce n'est pas l'iframe HTTPS imbriqué qui effectue cette demande de police, mais la page HTTP externe (contexte de navigation de niveau supérieur)!

Résumé

La page externe (contexte de navigation de niveau supérieur) est servie via HTTP. Iframe intégré est récupéré avec HTTPS. La demande HTTP d'un fichier de police créé par la page externe (et non par l'iframe incorporé) génère une erreur de contenu mixte dans la console Firefox 58.

Exemples de code

Pour donner un exemple concret, j’ai créé 2 stylos sur Plunker, qui sont servis via HTTP et importés (le site Plunker lui-même, pas mon code). Police WOFF police Awesome sur HTTP.

L'exemple with error, dans lequel l'iframe YouTube est intégré à HTTPS, génère l'erreur suivante dans la console Firefox 58: Blocked loading mixed active content “http://plnkr.co/css/font/Font-Awesome-More.woff”.

L'exemple Sans erreur, qui est le même code après la suppression de l'iframe, ne produit aucune erreur.

Des questions

  • Comment pouvez-vous avoir un contenu mixte sur un site Web chargé en utilisant le protocole HTTP? Je pensais que le contenu mixte ne peut exister que sur les sites Web chargés avec HTTPS. Le fait d'exiger des ressources via HTTPS (comme c'est le cas pour YouTube incorporé) rend-il tout le contenu requis via un contenu mixte HTTP?
  • Comment puis-je réparer l'erreur? Je ne prévois pas de servir le site Web sur HTTPS et je veux que mes polices se chargent correctement sur le serveur HTTP de production.
firefoxwebpackyoutube-apimixed-content
13
Robert Kusznier

Il semble que Firefox mette en cache les polices et tente d'exécuter une requête sur la police mise en cache en utilisant l'URL d'origine de la police ..... Cela entraîne une erreur de contenu mixte.

J'ai constaté ce problème avec les polices géniales lorsque j'ai déployé une application Web sur le serveur exécutant HTTPS, que j'avais développé sur un serveur local exécutant HTTP. Lors de la demande du site distant, Firefox signale:

Blocked loading mixed active content “http://localhost:8080/fontawesome-webfont.woff2”

Cela m'a impressionné car il n'y a pas de demande à localhost codée dans cette application Web.

Dans votre exemple, la police est chargée par

http://plnkr.co/css/apps/editor-1.6.1.css

qui est url(../font/Font-Awesome-More.woff)

L'un des CSS ou scripts chargés par l'iframe doit alors essayer de charger à nouveau cette police, éventuellement à l'aide d'une URL construite de manière dynamique.

Je ne connais rien à la stratégie de mise en cache des polices mise en œuvre dans Firefox - peut-être qu'ils identifient la police par son nom - mais l'une des solutions que j'ai trouvées pour mon cas consiste à "oublier ce site" localhost dans l'histoire de Firefox.

Une solution à votre cas pourrait être de basculer vers HTTPS

8
Uwe Voigt

J'ai eu le même problème. Je l'ai résolu en utilisant un chemin relatif au lieu d'un chemin absolu.

Comme mes polices sont appelées à partir de ce CSS "/styles/my.css",and mes polices se trouvaient dans"/fonts/Open_Sans ... "

Avant (avec erreurs FF): 

@font-face {
  font-family: "Open Sans";
  src: url("/fonts/Open_Sans/OpenSans-Light.woff2") format("woff2"),
  url("/fonts/Open_Sans/OpenSans-Light.woff") format("woff");
  font-weight: 300;
}

Après (sans erreur FF): 

@font-face {
  font-family: "Open Sans";
  src: url("../fonts/Open_Sans/OpenSans-Light.woff2") format("woff2"),
  url("../fonts/Open_Sans/OpenSans-Light.woff") format("woff");
  font-weight: 300;
}
4
bit-less

J'ai rencontré ce problème parce que mes serveurs en direct et intermédiaires étaient HTTPS et que ma copie locale/dev était HTTP.

Je l'ai résolu en générant mon CSS de manière dynamique et en utilisant des polices inline data: dans le CSS, plutôt que des références d'URL. Cela supprime toute information d'URL associée à une police et évite ainsi une éventuelle contamination de cache entre sites.

Dans mon cas, j'ai utilisé PHP, mais cela pourrait être changé pour n’importe quel langage côté serveur.

<?php
// Declare this as a CSS file for the browser
header('Content-type: text/css');

/*
 * Respond with 304 if the content was served recently
 *
 * The logic here is:
 *
 * We get a IMS date in the request e.g. 21:00 (Then)
 * We look at the current time e.g. 21:30 (Now)
 *
 * So (Now - Then) must be < 60 * 60
 */
if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE']))
{
    $thenTime = strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']);
    if(time() - $thenTime < 60 * 60)
    {
        header('HTTP/1.1 304 Not Modified');
        exit;
    }
}

// Tell the client the resource was modified on the last hour
$modifiedDate = gmdate('D, d M Y H:00:00 T', time());
header('Last-Modified: ' . $modifiedDate);

?>
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 300;
  src: local('Open Sans Light'),
       local('OpenSans-Light'),
       url(data:application/x-font-woff;charset=utf-8;base64,<?php echo base64font('open-sans-light.woff') ?>) format('woff');
}

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans'),
       local('OpenSans'),
        url(data:application/x-font-woff;charset=utf-8;base64,<?php echo base64font('open-sans-normal.woff') ?>) format('woff');
}

<?php

function base64font($file)
{
    $fontFolder = realpath(__DIR__ . '/../fonts');
    $data = file_get_contents($fontFolder . '/' . $file);
    $base64 = base64_encode($data);

    return $base64;
}

J'ai défini l'en-tête 304 pour entrer en jeu si la copie déjà transmise au navigateur est récente. Vous n'avez pas besoin de cela, mais cela améliorera les performances si vous le faites. Les définitions de polices changent rarement, vous pouvez donc prolonger ce délai sur les sites à fort trafic.

0
halfer

Puisque vous rencontrez des problèmes avec Firefox, suivez leur documentation, Comment réparer un site Web avec un contenu mixte bloqué :

Comment réparer votre site WebEdit

La meilleure stratégie pour éviter le blocage de contenu mixte est de servir tous les contenu en tant que HTTPS au lieu de HTTP.

Pour votre propre domaine, définissez tout le contenu en tant que HTTPS et corrigez vos liens. Souvent, la version HTTPS du contenu existe déjà, ce qui est juste nécessite l'ajout d'un "s" aux liens - http: // à https: //.

Toutefois, dans certains cas, le chemin peut simplement être incorrect pour le support dans question. Il existe des outils en ligne et hors ligne (selon votre système d'exploitation ) Tels que linkchecker pour vous aider à résoudre ce problème.

Pour les autres domaines, utilisez la version HTTPS du site, si disponible. Si HTTPS n'est pas disponible, vous pouvez essayer de contacter le domaine et leur demander si ils peuvent rendre le contenu disponible via HTTPS.

0
noogui