mod_cache

Apacheのキャッシュ用モジュール。

RFCに準拠した形でキャッシュメカニズムを提供する。つまり、基本的にはブラウザのキャッシュと同じ仕組み。

例えば、デフォルトの動作ではブラウザでF5キーを押すと、ブラウザはリクエストヘッダーにCache-Controlヘッダーを付加するので、サーバーはキャッシュを参照せずにオリジナルを参照する。（この動作は一例で、実際には設定で変更することができる）

特徴

・キャッシュはApacheの子プロセス毎に行われている。
・キャッシュはURLベースで行われる
・結果コンテンツがAccept-*に応じて参照しているとキャッシュ効果が無い

mod_cacheはコンテントネゴシエーションと相性が悪い

キャッシュはURLベースで行われているので、同一URLで別コンテンツを返すコンテントネゴシエーションと相性が悪いです。例えば、コンテンツの言語でja, en, frが用意されている場合に、例えばjaのコンテンツがキャッシュされてしまった場合には、en, frのコンテンツはキャッシュを参照せず、jaのコンテンツが有効な間はずっとオリジナルのコンテンツを参照するようになります。

参考: キャッシュサーバーはコンテンツがネゴシエーションされた結果であるかどうかをVaryレスポンスヘッダを参照して評価します。Varyに記されたヘッダーの一覧をリクエストとキャッシュ済みのレスポンスで評価し、一致しない場合には常にオリジナルを参照し、(すでにキャッシュ済みコンテンツがあるので)キャッシュを行いません。

この場合に、Apacheは"Vary header mismatch."というデバッグログを出力しますが、だからといってVaryヘッダーをmod_headerなどを利用してオリジナルのレスポンスから削除するべきではありません。Varyヘッダーを十分に理解せずに削除してしまうと意図しないコンテンツが出力されてしまう可能性があります。

Accept-Encodingについて

Accept-Encodingもコンテンツネゴシエーションの一種ですが、不運にも一番最初のアクセスがgzipやdeflate圧縮を要求していない場合には、未圧縮のコンテンツがキャッシュされてしまい、後続のgzipやdeflate圧縮で要求してきたリクエストはキャッシュを参照しません。

モダンなブラウザの多くは圧縮済みのコンテンツを理解するので、未圧縮のコンテンツを要求する場合には常にキャッシュを参照しないようにしてもいいかもしれません。

参考: キャッシュサーバーはリクエストに応じてContent-Encodingを変更して良いことになってますが、mod_cacheはそのようなことはしないようです。

(あとで書く)