FirefoxがJavaScriptファイルをキャッシュしない理由を見つけようとしてきました。 ChromeまたはIEでこの問題は発生しません。
サーバーの応答ヘッダーは次のようになります。
http://localhost:5012/bundles/scripts/jquery?v=FVs3ACwOLIVInrAl5sdzR2jrCDmVOWFbZMY6g6Q0ulE1
Cache-Control public, max-age=2592000
Content-Encoding gzip
Content-Length 42173
Content-Type text/javascript; charset=utf-8
Date Fri, 23 May 2014 14:33:28 GMT
Expires Sat, 23 May 2015 14:33:22 GMT
Last-Modified Fri, 23 May 2014 14:33:22 GMT
Server Microsoft-IIS/7.5
Vary Accept-Encoding
X-AspNet-Version 4.0.30319
X-Powered-By ASP.NET
fod_vary_store User-Agent
ご注意ください:
私の質問は、ここで見つけた別の質問の準重複です: Firefoxが画像とCSS をキャッシュしないのはなぜですか(受け入れられた答えなし)。 FireFoxの古いバージョンがクエリ文字列でリソースをキャッシュしないことを示唆していました。ただし、一部のユーザーは、この問題は新しいバージョンで修正されたと回答しました。
クエリ文字列でリソースをキャッシュすることはお勧めしません。通常、クエリ文字列は動的リソースを表します。ただし、IEおよびChromeは、Cache-Control
およびExpires
ヘッダーに基づいてキャッシュします。 Firefoxはキャッシュする必要がありますが、これは検証が弱いため、つまりEtagを使用していない可能性があります。 Etagを使用すると、Firefoxのキャッシュ制御メカニズムの強力な検証が強制されます。 Firefoxは RFC 2616 セクション 13.3.2 を追跡しようとします。サーバーでファイルが変更されていない場合は、304 Not Modifiedの応答が表示されます。
Originサーバーがレスポンスのキャッシュを明示的に禁止していない限り、リソースへのGETおよびHEADメソッドの適用は、これらのレスポンスがキャッシュから取得された場合に誤った動作を引き起こす副作用がありません。それらはまだ副作用があるかもしれませんが、キャッシュはそのキャッシュ決定でそのような副作用を考慮する必要はありません。キャッシュは常に、Originサーバーのキャッシングに関する明示的な制限を遵守することが期待されています。
このルールには1つの例外があります。一部のアプリケーションでは、従来、クエリURL(rel_path部分に「?」を含むもの)でGETとHEADを使用して重大な副作用を伴う操作を実行していたため、キャッシュはそのようなURIへの応答を新鮮なものとして扱わないでくださいサーバーが明示的な有効期限を提供しない限り。 これは、具体的には、そのようなURIに対するHTTP/1.0サーバーからの応答がキャッシュから取得されるべきではないことを意味します。関連情報については、セクション9.1.1を参照してください。
したがって、クエリ文字列は、htmlを含む動的コンテンツをキャッシュすべきではないと想定する必要があります。ただし、これはIEおよびChromeの場合ではありません。これらは、指定された要求URIのCache-ControlおよびExpiresヘッダーに注意を払います。
つまり、クライアントとサーバーの実装に本当に依存します。
F5キーを使用してリロードし、開発者ツールを調べるときのFirefoxでは、e-tagヘッダーを使用すると、403キャッシュがキャッシュヒットに対して変更されていません。
したがって、IIS内でETagサポートを有効にしてみてください。
参照:
http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/