HTTPプロトコルを使用して提供されるWebサイトを開発しています。開発では、Webpackをwebpack-dev-serverとともに使用します。これは、http://localhost:9090
でローカルにページを提供します。
Firefox 58コンソールで次の mixed content フォントファイルの読み込みに関するエラーが表示されて驚いた。私にとって奇妙なのは、ページがHTTPSではなくHTTPを使用して提供されるため、混合コンテンツエラーはHTTPSページのみに限定されると考えたためです。
`Blocked loading mixed active content “http://localhost:9090/b1aa06d82e70bbd5a14259a94c9bbb40.ttf”
エラーの原因は、ページの<iframe>
(<iframe src="https://www.youtube.com/embed/...>
)に埋め込まれたYouTubeビデオであることがわかりました。 YouTubeの埋め込みを削除するとすぐに、コンソールからエラーが消えます。
私はこの動作を理解していません。このフォント要求を行っているネストされたHTTPS iframeではなく、外側のHTTPページ(トップレベルのブラウジングコンテキスト)です。
外側のページ(トップレベルのブラウジングコンテキスト)は、HTTPを使用して提供されます。埋め込みiframeのみがHTTPSを使用して取得されます。 Firefox 58コンソールでは、外部ページが作成するフォントファイル(埋め込みiframeではない)のHTTP要求により、混合コンテンツエラーが生成されます。
実例を示すために、Plunkerに2つのペンを作成しました。これはHTTP経由で提供され、(私のコードではなくPlunkerサイト自体)WOFFフォントFont Awesome over HTTPをインポートします。
HTTPS経由でYouTube iframeが埋め込まれている例With errorは、Firefox 58コンソールで次のエラーを生成します:Blocked loading mixed active content “http://plnkr.co/css/font/Font-Awesome-More.woff”
。
例Without errorは、iframeを削除しただけの同じコードですが、エラーを生成しません。
Firefoxはフォントをキャッシュし、フォントが最初に配信されたURLを使用して、キャッシュされたフォントへのリクエストを実行しようとするようです。これは混合コンテンツエラーにつながります。
HTTPを実行しているローカルサーバーで開発したHTTPSを実行しているサーバーにWebアプリケーションを展開したときに、フォントが素晴らしいフォントでその問題を見ました。 Firefoxがレポートするリモートサイトをリクエストする場合:
_Blocked loading mixed active content “http://localhost:8080/fontawesome-webfont.woff2”
_
そのWebアプリケーションにコーディングされたlocalhostへの要求がないため、私は感銘を受けました。
あなたの例では、フォントは
url(../font/Font-Awesome-More.woff)
です
IframeによってロードされたCSSまたはスクリプトの1つは、動的に構築されたURLを使用して、そのフォントを再度ロードする必要があります。
Firefoxに実装されているフォントキャッシング戦略については何も知りません-それらは名前でフォントを識別するかもしれませんが、私のケースで見つけた解決策の1つは、Firefoxの履歴で「このサイトを忘れる」localhostです。
あなたの場合の解決策は、 [〜#〜] https [〜#〜] に切り替えることです
同じ問題がありました。 absoluteの代わりにrelativeパスを使用して解決しました-)パス。
私のフォントはこのCSS "/styles/my.css"から呼び出されており、私のフォントは "/ fonts/Open_Sans ..."にありました。
前(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;
}
後(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;
}
ライブおよびステージングサーバーがHTTPSであり、ローカル/開発コピーがHTTPであるため、この問題が発生しました。
CSSを動的に生成し、インラインdata:
URL参照ではなく、CSSのフォント。これにより、フォントに関連付けられているURL情報がすべて削除されるため、クロスサイトキャッシュの汚染を回避できます。
私の場合、PHPを使用しましたが、これは任意のサーバー側言語に変更できます。
<?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;
}
ブラウザーに既に提供されているコピーが最近のものである場合に作動するように、304ヘッダーを設定しました。これは必要ありませんが、実行するとパフォーマンスが向上します。フォント定義はめったに変更されないため、トラフィックの多いサイトではこの遅延を長くすることができます。
Firefoxで問題が発生しているため、指定されたドキュメントに従ってください ブロックされた混合コンテンツでWebサイトを修正する方法 :
ウェブサイトの修正方法Edit
混合コンテンツのブロックを回避する最善の戦略は、すべてのコンテンツをHTTPではなくHTTPSとして提供することです。
独自のドメインでは、すべてのコンテンツをHTTPSとして提供し、リンクを修正します。多くの場合、コンテンツのHTTPSバージョンが既に存在し、これにはリンクに「s」を追加するだけで済みます-http://からhttps://。
ただし、場合によっては、問題のメディアへのパスが正しくないことがあります。これを解決するのに役立つlinkcheckerなどのオンラインツールとオフラインツール(オペレーティングシステムによって異なります)があります。
他のドメインについては、利用可能な場合はサイトのHTTPSバージョンを使用します。 HTTPSが利用できない場合は、ドメインに連絡して、HTTPSを介してコンテンツを利用可能にするかどうかを尋ねることができます。