告白：私が管理しているサイトには、主にサーバーのデフォルト構成に基づいてキャッシュ制御に関するさまざまなルールがあり、ページ速度とY-Slow Firefoxプラグインの推奨事項とGoogleのSpeed Tracerのネットワークリソースビューに基づいています。Cache-Controlは、何をするかによってプライベート/パブリックに設定されます。ETagの/ Last-Modifiedヘッダーは、Y-Slowが何か問題があることを示唆し、Amazonのファイルを手動でgzipするときにVary-Accept-Encodingが必要な場合にのみ変更されますCloudFront。
さまざまなオプションとそのオプションに関する資料を読むと、矛盾する情報、壊れたプロキシのルール、カーゴカルトの構成があるようです。上記の分析ツールによって提供される公式情報は、統一された戦略としてではなく、各トピックを個別に処理するため、まったくアクセスできません（技術の相互参照はありません）。
たとえば、速度解析ツールがETagを使用するサイトを、キャッシングを支援することを目的としている場合、ETagを使用しないサイトと同じと評価することは意味がないようです。
プラットフォームに依存しないキャッシュ制御戦略の厳格なルールは何ですか？
編集：
リンク経由ジェフ・アトウッドの記事はすばらしい深さでのキャッシングについて説明します。
記録のために、ここには厳しい規則があります：
ファイルがGZIPなどを使用して圧縮されている場合 -プロキシは「cache-control：private」を使用します。プロキシは、それをサポートしていないクライアントに圧縮バージョンを返す場合があります（ブラウザキャッシュはこのようにマークされたファイルを保持します）。また、「Vary：Accept-Encoding」を含めて、圧縮可能であると言うことを忘れないでください。
Last-ModifiedをETagと組み合わせて使用-ベルトとブレースの使用は両方のバリデータを提供しますが、ETagは変更時間だけではなくファイルの内容に基づいており、両方がすべてのベースをカバーします。注： AOLのPageTestには、何らかの理由でETagsに対する単純なアプローチがあります。同じコンテンツをホストするために複数のサーバーでApacheを使用している場合、実際に同じライブファイルシステムを使用していない限り、ETagsから暗黙的に宣言されたinodeをFileETagディレクティブから除外して削除します。
可能な限り「cache-control：public」を使用します -これは、ページの残りがHTTP認証などを必要とする場合でも、プロキシサーバー（およびブラウザーキャッシュ）がコンテンツを返すことを意味します。