GlassfishサーバーにリソースをキャッシュするChromeに問題があります。expiresおよびno-cacheヘッダーが送信されておらず、リソース(約4 MBのSWFファイル)がキャッシュされていますby Chrome-Last-Modifiedヘッダーの存在にもかかわらず。
時々Chromeは304コードを取得し、他の場合は単に200をキャッシュから取得します。304を理解しています-Chromeキャッシュバージョンを含む最新の最終更新日。ただし、ヘッダー情報を返さず、Chromeは単にファイルを想定しているように見える)200(キャッシュから)チェックする代わりに変更されていません。
Google自身のサイトの状態 以下:
HTTP/Sは、ブラウザによる静的リソースのローカルキャッシュをサポートしています。最新のブラウザの一部(例:IE 7、Chrome)は、ヒューリスティックを使用して、明示的なキャッシュヘッダーを持たないすべてのリソースをキャッシュする期間を決定します。
しかし、これは決定的な答えを提供しません。このヒューリスティックはどこにでも公開されていますか?決まった答えはないかもしれませんが(30日間など)、一般的なガイドラインが役立つでしょう。さらに、Last-Modifiedが設定されている場合、なぜChromeが最初にそれを確認することに煩わされないのか理解できません。
DEFAULT_CACHE_TIME = 300
「DEFAULT_CACHE_TIME」を http://code.google.com/p/chromium/source/search?q=DEFAULT_CACHE_TIME&origq=DEFAULT_CACHE_TIME&btnG=Search+Trunk で検索すると、上記が見つかりました。
DEFAULT_CACHE_TIMEを含む「chromeextensionsdocs.py」というファイルがあります。
私 信じる これは http://code.google.com/appengine/docs/python/memcache/overview.html にある例に基づく秒です
「chromeextensionsdocs.py」では、DEFAULT_CACHE_TIMEがmemcache.add
の最後のパラメーターとして送信されます
これが正しい値であるかどうかは完全にはわかりませんが、ピースをまとめるときのようです。
ブラウザがキャッシュされた応答を新しいと見なす時間は、通常、最後に変更されたときからの相対時間です。
Originサーバーは常に明示的な有効期限を提供するとは限らないため、明示的な時間が指定されていない場合、キャッシュは他のヘッダーフィールド値を使用するアルゴリズムを使用してヒューリスティックな有効期限を割り当ててもよい(MAY)... Last-Modifiedヘッダーフィールド([RFC7232]のセクション2.2)があるため、キャッシュはその時点から間隔のほんの一部に過ぎないヒューリスティックな有効期限値を使用することが推奨されます。この割合の一般的な設定は10%です。 [ https://tools.ietf.org/html/rfc7234#section-4.2.2]
Chrome(および他のブラウザ)がその値を計算する方法の詳細は、ソースコードで見つけることができます( 例Chrome v49 )。Chromeは、Last-Modifiedヘッダーに対する値も計算します。
( この投稿へのクレジット )