RFC 2616に準拠していることがアドバタイズされているため、リバースプロキシとしてApache 2.4.3を使用しています。私のアプリは次のようなヘッダーを使用して、プロキシでのキャッシュを有効にします。
Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: A
Vary: X-Group
ETag: W/"foo1"
最初のリクエストがキャッシュをウォームアップした後、アプリが次のように応答するように変更された場合:
Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: B
Vary: X-Group
ETag: W/"foo2"
ApacheのIf-None-MatchヘッダーがOriginで生成されたETagと一致する場合、アプリは304 NotModifiedで応答します。ただし、Apacheは2番目の200応答をキャッシュし、replaces "foo1"レコードを、異なるETagで両方の応答をキャッシュする代わりに、新しい応答でキャッシュします。したがって、If-None-Match: W/"foo1", W/"foo2"
の代わりに、次の再検証要求はIf-None-Match: W/"foo2"
だけです。そのため、キャッシュは常にヒットするのではなく、常にミスを起こします。
RFC 2616セクション12.1から:
ただし、オリジンサーバーはこれらのディメンションに限定されず、リクエストヘッダーフィールドの外側やこの仕様で定義されていない拡張ヘッダーフィールド内の情報など、リクエストのあらゆる側面に基づいて応答を変更できます。
Varyで次の組み合わせを試しました。
Vary: X-Foo
Vary: *
Vary: User-Agent
また、強力なETagと弱いETagの両方を試しましたが、Apacheに2つの応答を同時にキャッシュさせることができなくても、常に前の応答よりも節約されます。ページの複数の差異を保存できない場合、ETagは役に立ちません。Last-Modifiedも同様に適切です。
Apache 2.4ドキュメントから:
mod_cacheは、RFC 2616準拠のHTTPコンテンツキャッシングフィルターを実装し、Varyヘッダーを含むコンテンツネゴシエーション応答のキャッシングをサポートします。
「応答」が複数形であることに注意してください。 HTTP仕様を誤って解釈しているのでしょうか、それともApache 2.4がETagを完全にサポートしていないのでしょうか?
次のような例をいくつか挙げます。
Cache-Control: public, s-maxage=0
Expires: ... (+1 day)
X-Group: A
Vary: X-Group
ETag: W/"foo1"
特にVary: X-Group
ヘッダーに気づきました。 X-Group
はリクエストヘッダーですか、それともレスポンスヘッダーですか?
RFC 2616セクション14.44 に従って、Vary
は、異なるコンテンツになるrequestヘッダーをリストする必要がありますOriginサーバーからの表現。あなたの例から、X-Group
が応答ヘッダーである可能性があります。その場合、mod_cacheは指定されたリソースの複数のバージョンを格納しません。
試すことができる1つのことは、Vary: If-None-Match
を設定することです。これにより、mod_cacheは各ETagのリソースのバージョンを保存できます。確かに、私はこれを試していません。それが機能すると仮定すると、1つの欠点は、クライアントからの最初の要求がキャッシュミスになることです。