IIS 7.5のキャッシュ制御ヘッダー
クライアント側（Webブラウザー）のキャッシュと、それがIIS 7.5キャッシュ制御ヘッダーに関連してどのように機能するか）に頭を悩ませようとしています。
特に：
クライアントにキャッシュされたリソースの再読み込みを強制する場合、IISを構成する必要がありますか？
サーバー上のリソースに最新の変更日（またはETag値）がある場合、期限切れのWebコンテンツをすぐに設定する必要がありますか？
現在、キャッシュヘッダーは設定していません。したがって、キャッシュなしのキャッシュヘッダーを設定すると（これは、すぐに期限切れのWebコンテンツに相当すると思います）、Webブラウザーに特定のファイルの新しいバージョンを取得するように強制します。または、ブラウザは現在のコピーが古くなっていると見なした後でのみ新しいバージョンを要求し、それ以降はキャッシュしませんか？
キャッシュ制御フラグを1週間に設定してから、変更を加えることを知る8日前に、キャッシュ制御をたとえば30分に設定することをお勧めしますか？
しかし、それを実行した後、問題が発生したためにユーザーキャッシュからアイテムをすぐに期限切れにする必要がある場合、どうすればよいですか？
クライアント/ユーザーエージェントのキャッシュを理解する1つの方法は、ブラウザーをそれ自体の中間キャッシュを実装していると見なすことです（実際には、Cache-Control: privateでアドレス指定されています）。これにより、すべての用語が単純な要求と応答のパターンに抽象化され、ほとんどの場合、ブラウザのキャッシュはプロキシまたは中間キャッシュと同じように動作します。これを覚えておくと、IETF RFC 2616の主題に関する信頼できるドキュメントを読むときに役立ちます： http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 。
http://technet.Microsoft.com/en-us/library/cc770661（v = ws.10）の説明に従って、「Expires」ヘッダーを「Immediately」（
Cache-Control: no-cacheを送信）に設定します。 .aspx および http://msdn.Microsoft.com/en-us/library/ms689443（v = vs.90）.aspx 。いいえ。Cache-Controlヘッダーを送信しない場合、IISはリソースの最新バージョンを送信し、クライアントはLast-ModifiedヘッダーまたはETagのいずれかからそれを認識する必要があります。
最初のステートメントは正しいです。
no-cacheを送信すると、リソースがすでにキャッシュされている場合でも、毎回リソースを要求するようにクライアントに指示されます。一部のクライアントは、とにかくそのようなリソースの誤動作とキャッシュを行いますが、must-revalidateを使用して、新しいコピーを確実に取得することもできます。
ベストプラクティスに関しては、キャッシュする期間はアプリケーションとユーザーのニーズによって異なります。上記の問題を解決するためにいつでもCache-Control: must-revalidateを送信できるため、キャッシュの有効期限をグローバルに変更する必要はありません。