web-dev-qa-db-ja.com

Apache2.4を使用したRFC2616

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を完全にサポートしていないのでしょうか？

httpreverse-proxyetagsapache-2.4
6
ColinM

次のような例をいくつか挙げます。

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つの欠点は、クライアントからの最初の要求がキャッシュミスになることです。

1
Vortura