cache-controlのデフォルト値は何ですか？
私の問題は、ブラウザが既にリソースを変更していても、一部のリソースをオーバーキャッシュする場合があることです。しかし、F5の後、すべてが順調です。
私はこの事例を午後ずっと勉強しました。これで、「最終変更」または「キャッシュ制御」のポイントを完全に理解しました。そして、私はissue（ちょうど.js？versionまたは明示的なmax-age = xxxx）を解決する方法を知っています。しかし、問題はまだ解決されていません：ブラウザーが応答ヘッダーを処理する方法without "Cache-Control"は次のようになります。
Content-Length: 49675
Content-Type: text/html
Last-Modified: Thu, 27 Dec 2012 03:03:50 GMT
Accept-Ranges: bytes
Etag: "0af7fcbdee3cd1:972"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 24 Jan 2013 07:46:16 GMT
「Enter in the bar」のときに、それらを明確にキャッシュします
RFC 7234 デフォルトでブラウザとプロキシが行うべきことの詳細：
キャッシュはHTTPの完全にオプションの機能ですが、キャッシュされた応答を再利用することが望ましく、要件またはローカル設定でそれが妨げられない場合、そのような再利用はデフォルトの動作であると想定できます。したがって、HTTPキャッシュの要件は、キャッシュが常に特定の応答を格納および再利用することを義務付けるのではなく、キャッシュが再利用できない応答を格納すること、または格納された応答を不適切に再利用することを防ぐことに焦点を当てています。
キャッシュは通常、ブラウザでデフォルトで有効になっているため、cache-controlを使用して、この動作をカスタマイズするか、無効にすることができます。
キャッシュはHTTPの完全にオプションの機能ですが、キャッシュされた応答を再利用することが望ましく、要件またはローカル設定でそれが妨げられない場合、そのような再利用はデフォルトの動作であると想定できます。したがって、HTTPキャッシュの要件は、キャッシュが常に特定の応答を格納および再利用することを義務付けるのではなく、キャッシュが再利用できない応答を格納すること、または格納された応答を不適切に再利用することを防ぐことに焦点を当てています。 [ https://tools.ietf.org/html/rfc7234#section-2]
ブラウザがキャッシュされた応答を新しいと見なす時間は、通常、最後に変更されたときからの相対時間です。
Originサーバーは常に明示的な有効期限を提供するとは限らないため、明示的な時間が指定されていない場合、キャッシュはヒューリスティックな有効期限を割り当て、他のヘッダーフィールド値（Last-Modified timeなど）を使用するアルゴリズムを採用する場合があります... Last-Modifiedヘッダーフィールド（[RFC7232]のセクション2.2）があるため、キャッシュはその時点から間隔のほんの一部に過ぎないヒューリスティックな有効期限値を使用することが推奨されます。この割合の一般的な設定は10％です。 [ https://tools.ietf.org/html/rfc7234#section-4.2.2]
この投稿 には、さまざまなブラウザーがその値を計算する方法の詳細が記載されています。
デフォルトのcache-controlヘッダーは次のとおりです：Private
キャッシュメカニズムは、このページをプライベートキャッシュにキャッシュし、単一のクライアントにのみ再送信します。 これはデフォルト値です。ほとんどのプロキシサーバーは、この設定のページをキャッシュしません。
http://msdn.Microsoft.com/en-us/library/ms524721%28v=vs.90%29.aspx をご覧ください
鮮度の有効期間は、いくつかのヘッダーに基づいて計算されます。 「Cache-control：max-age = N」ヘッダーが指定されている場合、フレッシュネスライフタイムはNに等しくなります。このヘッダーが存在しない場合（非常によくあるケースです）、Expiresヘッダーが存在するかどうかがチェックされます。 Expiresヘッダーが存在する場合、その値からDateヘッダーの値を引いた値が鮮度の有効期間を決定します。最後に、どちらのヘッダーも存在しない場合は、Last-Modifiedヘッダーを探します。このヘッダーが存在する場合、キャッシュの鮮度の有効期間は、Dateヘッダーの値からLast-modifiedヘッダーの値を10で割った値に等しくなります。
ソース： https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#Freshness
キャッシュコントロールヘッダーがない場合、ブラウザは新しい（？）ページを読み込むたびにリソースを要求します。 F5を押すと、そのページ内のキャッシュされたアイテムが無効になり（または論理的に削除され）、ローカルバージョンが利用できないため、完全なリロードが強制されます-ブラウザがそれらのリソースをキャッシュから削除してから再度要求するかどうかはわかりません。
面白い部分は、一部のブラウザー内にいくつかの「追加の」設定があり、ページの読み込みごとに1回だけリソースを要求するなどの最適化が行われることです。カウンタのようにリクエストごとに変化する画像がある場合、複数回使用しても、この画像の1つのバージョンのみが表示されます。
次の方法は、ブラウザーが何らかの「優先」ローカルキャッシュを適用することにより、明示的にnocacheとして設定されていない画像を再利用することです。再検証するように設定する必要があるたびにリクエストを取得し、expiredを-1などに設定する必要がある場合。
そのため、何も指定しないリソースに応じて、仕様の読み取りから予想されるものとは異なるデフォルトがトリガーされることがよくあります。
また、ソースがローカルであるか、ドライブであるか、実際の遠隔のインターネットサーバーであるかについて、異なる動作が存在する場合があります。とは言っても、すべてのブラウザが異なる動作をするわけではなく、私はかなり制限されています。
役立つのは、www.google.comをチェックアウトし、ページリクエストのトラッキングピクセルを検索することです（サブドメインにランダムな部分があるmetrics.gstats.comから2つの1x1ピクセルがリクエストされます）。
Firebugを使用してヘッダーをチェックアウトすると、可能な方法でnocacheディレクティブが指定されていることがわかります。ヘッダーは次のようになります。
Alternate-Protocol 443:quic
Cache-Control no-cache, must-revalidate
Content-Length 35
Content-Type image/gif
Date Mon, 25 Nov 2013 14:33:30 GMT
Expires Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified Tue, 14 Aug 2012 10:47:46 GMT
Pragma no-cache
Server sffe
X-Content-Type-Options nosniff
X-Firefox-Spdy 3
X-XSS-Protection 1; mode=block
これを設定として試して、これがブラウザーが変更されたリソースを取得しなかったという問題を解決するかどうかを確認してください。 must-revalidateディレクティブは、プロキシキャッシュでさえ毎回リソースを要求し、304 Not Modified応答をチェックします。
私は現在、似たようなことを経験しています。 etagを設定するlocalhost接続がありますが、起こるのはキャッシュが決して尋ねないということだけです。キャッシュ情報などを設定しませんでした。 FireFoxがリソースを再度要求しないように、etagシームを単独で指定します。だから私はあなたの問題に似た何かを経験します。
あなたの場合、あなたはEtag: "0af7fcbdee3cd1:972"は応答ヘッダーにあるため、キャッシュされます。