4つのユースケースに対して送信する最も良いHTTPヘッダーを理解しようとしています。私は、ユーザーエージェント/プロトコルバージョンの盗聴に依存しないヘッダーを思いつきたいと思っていますが、それ以外のものがあればそれを受け入れます。私が好きなようにすべてのヘッダを選択することができるように、すべてのURLは完全カスタムのハンドラを通してフェッチされます。これは中間プロキシとユーザエージェントに関するすべてです。可能であれば、これはHTTP/1.0とHTTP/1.1の両方のクライアントと互換性があります。複数のソリューションが存在する場合、最良のものが配線を介して送信されるときに最短のものになります。HTTPヘッダー：キャッシュと履歴のメカニズムを制御する
静的パブリックコンテンツ
すべての「静的パブリックコンテンツは、」HTTPが本当にすべてに約あるというものである：URLが同じであれば、内容は同じです。私はこれを簡単に行うことができます：例えば、ユーザプロファイルアイコンをhttp://domain.com/profiles/xyz/icon/1234abcdに入れます。ここで、 "1234abcd"はアイコンのファイル内容のSHA-1です。今後iconに変更すると、新しいURLを作成し、新しいアイコンを使用する既存のすべての参照元を変更します。これが永遠にキャッシュされ、共有される可能性があることを宣言するための最良のヘッダは何ですか？私は現在、行に沿って何かを考えています：
Date: <current time>
Expires: <current time + one year>
ユーザエージェントとプロキシによるキャッシュを許可するには十分ですか？ Last-ModifiedまたはPragmaが必要ですか？
静的非パブリックコンテンツ
すべての「静的非パブリックコンテンツは、」静的ですが、誰もが利用できない場合がありますものです。実際には、このコンテンツは選択されたログインユーザだけが利用できます（セッションはセッションのUUIDを保持するセッションCookieで保持されます）。 URLが同じ場合、コンテンツは同じです。しかし、その応答は公開されていません。ユースケースは、ソーシャルネットワークサービスで選択された友人に共有される画像である可能性があります。私は現在、線に沿って何かを考えている：
Date: <current time>
Expires: <current time>
Cache-Control: private, max-age=<huge number>, s-maxage=0
は、ユーザエージェントによってキャッシュを許可するとしてプロキシを無効にするには、この十分ですか？ Pragmaが必要ですか？
揮発公開コンテンツ
すべて「揮発性のパブリックコンテンツは、」揮発性と誰もが利用できるものです。ログインしていないときは、http://slashdot.org/のフロントページのようなものです。意図していないURLのコンテンツをすばやく更新できるようにすることです。 私はユーザエージェント履歴のメカニズムを壊したくないことに注意してください（つまり、揮発性ページから何かをクリックしてから、戻るボタンを押すと、サーバから揮発性ページを取得してはいけません。サーバからリソースを取得する必要があります）。私は現在、行に沿って何か考えています：
キャッシングを防止するのに十分ですが、履歴メカニズム（戻るボタン）を許可するには十分ですか？もし私がCache-Control: no-store, must-revalidateを送ると、私は再ロードを強制することができますが、これは私が望むものではないことがわかります。 Last-ModifiedまたはPragmaが必要ですか？
これは公開されていますが、揮発性であるため中間プロキシがこれをキャッシュできるようにするのはおそらく意味がありません。
揮発性非パブリックコンテンツ
すべて「揮発性非パブリックコンテンツは、」揮発性、みんな（プライベート）に利用できないものです。あなたがログインしているときには、http://slashdot.org/のフロントページのようなものがあります。その意図は、変化していないURLでコンテンツをすばやく更新できるようにすることです。 私はユーザエージェント履歴のメカニズムを壊したくないことに注意してください（つまり、揮発性ページから何かをクリックしてから、戻るボタンを押すと、サーバから揮発性ページを取得してはいけません。サーバからリソースを取得する必要があります）。私は現在、行に沿って何かを考えています：
Date: <current time>
Expires: <current time>
Cache-Control: private, max-age=0, s-maxage=0
これはキャッシングを防止するのに十分ですが、履歴メカニズム（戻るボタン）を許可するには十分ですか？ Pragmaが必要ですか？
まだ私の提案のヘッダーでのテスト必要なもの：
- は、プライベートコンテンツがHTTP/1.0プロキシから漏洩されないことを確認してください。
- プロキシでキャッシュが正しく機能することを確認します。
- ユーザエージェントでキャッシュが正しく動作することを確認してください。
- ユーザエージェント履歴メカニズムがユーザエージェントで動作することを確認します（すべてのケース）。
- 揮発性ページへのリンクをたどると、サーバーから新しいコンテンツが取得されることを確認します。
- HTTPの代わりにHTTPSを使用する場合は、すべての結果を確認してください。
私は以前の似たような質問については、http：//stackoverflow.com/questions/2970938/ideal-http-cache-control-headers-for-different-types-of-resourcesに気付いています。 3つの重要なパズルの欠点：バックボタンの動作、ユーザーエージェントの互換性、HTTP/1.0プロキシのサポート。 –
また、よく引用される他のソースhttp://www.mnot.net/cache_docs/も、バックボタンとHTTP/1.0プロキシのサポートで、実際のユーザーエージェントの動作に対処していません。 –
ここにCache-Controlに関する記事があります：http://palisade.plynt.com/issues/2008Jul/cache-control-attributes/ - 現実世界のバックボタンの動作、ユーザエージェントの互換性、HTTP/1.0プロキシのサポートもありません。 –