3

FirefoxとCDNでホストされているフォントへのアクセスに関する非常に厄介な問題の解決策をどうにかして見つけたと思いましたが、ここにIE9があります。

私は最近、IE9のキャッシュの問題で非常に苛立たしい問題を見つけ、このブログ投稿（IE9 Redirect Caching Nightmare）に偶然出くわし、実際の問題についてより多くのことを教えてくれました。

上記が実際に問題であるかどうかはわかりませんが、十分に近いようです。

問題：

同じサーバーを指す2つのドメイン（ベースドメインとサブドメイン）でセットアップされたWebサイトがあり、Cloudfrontによって提供されるAmazonS3でホストされているCDNからの同じリソースセットを使用しているまったく同じWebサイトを提供しています。

https://example.com
https://www.example.com

@ font-faceを使用してCSSファイルからフォントをロードすると、IE9開発ツールコンソールにこの種のエラーメッセージが表示されます。

CSS3117: @font-face failed cross-origin request. Resource access is restricted.

これは、最初にいずれかのURLをロードし、次にもう一方のURLにアクセスしたときに発生します。IE9はで実行されていませんCompatibility Mode。実行中Document Mode: IE9 Standardsです。

CORSについての私の限られた理解と、Access-Control-Allow-OriginHTTPヘッダーを設定する必要性から、S3 CORSポリシーで忠実に設定しました。これは、Firefoxで完全に機能します。

両方のドメインからのリクエストは、CDNリソースをリクエストするときにそれぞれのヘッダーを取得します。

IE9はキャッシュを使用して最適化を試み、リダイレクトもキャッシュしたようです。Access-Control-Allow-Originヘッダーもキャッシュされるため、これにより問題が発生します。CDNサーバーにリクエストを送信しないと、Access-Control-Allow-Originドメインごとにヘッダーを変更できません。

そのため、リクエストがからhttps://www.example.comであるにもかかわらず、Access-Control-Allow-Originがであるという状況が残りhttps://example.comます。これにより、上記のエラーメッセージでリソース制限の問題が発生します。

詳細： Firefox 19でチェックしたところ、上記の状況が実際に発生しましたが、IE9と同じような厳格な制限はありません。https://www.example.com情報を要求するサブドメイン（ ）access-control-allow-originは、メインドメイン（https://example.com）のを受け入れます。Chrome（Webkit）は気にしないようです。どのブラウザの動作の実装が正しいか迷っています。

CDNの現在の設定では、ChromeとFirefoxが、すべてのwwwサブドメインリクエストをメインドメインに自動的に再ルーティングしているようです。アドレスバーにサブドメインを何度も入力しようとすると、wwwChromeとFirefoxはそれに従います。一方、IE9は、アドレスバーに入力されたアドレスに移動します。IE9はここでは奇妙なもののようですが、どのブラウザの動作が実際に正しいかはわかりません。

使いやすさの観点から、ChromeとFirefoxは「正しい」動作のようです。

既知の可能な解決策：

  1. Access-Control-Allow-Originすべてを許可するようにヘッダーを設定します。*
  2. ブラウザでキャッシュをオフにする
  3. 1つのドメインを別のドメインにリダイレクトする
  4. クエリ文字列を使用して、リソースに対するさまざまなドメイン呼び出しを区別します
  5. フォントをdata-uriとしてCSSに埋め込みます

解決策1の場合、許可する特定のドメインを設定したいだけだと言ってみましょう。

ソリューション2の場合、すべてのブラウザーに設定する場合は最適ではありません。また、サイトは通常、望ましいダウンロード速度よりも遅いモバイルデバイスで実行する必要があります。

解決策3については可能ですが、IE9のキャッシュの問題に直接対処する解決策に興味があります。

ソリューション4の場合、特にリソースがから呼び出される場合、実装は非常に困難です@font-face。問題を回避するためにフォントをロードするためだけに、異なる行の異なるドメイン呼び出しに対してCSSを動的に再生成する必要があるということですか？CSS自体の目的を打ち破り、そのためのリソースをキャッシュしているようです。

編集：スタイルシートは機能しますが、フォントの読み込みは機能しません。

ソリューション5の場合、特にフォントファイルが定期的に変更される場合は、メンテナンスと更新が面倒です。

質問：この特定のケースでIE9のリダイレクトキャッシュ動作を具体的に処理する既知の方法はありますか？

回答とコメントは大歓迎です。前もって感謝します！

編集：より多くのブラウザテスト情報。

4

2 に答える 2

0

解決策1：この質問を 確認してください。

解決策4： CSSファイルの名前をstyle.phpに変更し、適切なリソースを呼び出すために必要なコードを使用します。

ページ上部のコンテンツタイプを設定します。

<?php
    header("Content-type: text/css; charset: UTF-8");
?>

クリス・コイエのstyle.phpに関する詳細情報。

于 2013-03-12T22:26:14.793 に答える
0

IE10 と IE11 でも同じ奇妙な動作を発見しました。

ブラウザのキャッシュをリセットすると、問題なくフォントが読み込まれます。また、互換モードの有効化と無効化。

しかし、別のサブドメインに切り替えると、リクエスト ヘッダーが最後のリクエストの URL であるレスポンス ヘッダーと一致しないため、IE はフォントをレンダリングしません。また、バケットの定義が *.ourdomain.com であっても、IE は常に完全な URL を表示します。

そのため、Web フォントなどのアセットへのクロス オリジン リクエストを許可することに関する一般的な問題は、S3 バケットに CORS 権限を追加することで解決されました。これにより、Firefox で Web フォントが完全に機能するようになりました。

しかし、 *を回避して、応答ヘッダーをキャッシュしないように IE に指示する方法はまだわかりません。

于 2014-01-15T13:59:11.357 に答える