私は私のキャッシュ戦略に関して基本的な動作をしようとしています:ファイルはキャッシュされ、毎回サーバーで再検証される必要があります。ですから、Apacheに304を返送してもらいたいのです。
ブラウザの更新ごとに発生するダイアログは次のとおりです。
Status Code:200 OK
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie: ...
Host:...
If-Modified-Since:Tue, 14 Oct 2014 15:10:37 GMT
If-None-Match:"1461-505636af08fcd-gzip"
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36
Response Headers
Accept-Ranges:bytes
Cache-Control:No-cache
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:1412
Content-Type:text/html
Date:Tue, 14 Oct 2014 16:58:05 GMT
ETag:"1461-505636af08fcd-gzip"
Keep-Alive:timeout=5, max=99
Last-Modified:Tue, 14 Oct 2014 15:10:37 GMT
Server:Apache/2.4.6 (Ubuntu)
Vary:Accept-Encoding
(これはchrome devtoolsからのもので、キャッシュを無効にするがオフになっています)
応答にCache-Control:No-cacheヘッダーが含まれており、If-modified-sinceヘッダーがLast-modifiedと一致していることがわかります。 ETagも一致します。
その場合、Apacheは304を送信すべきではありませんか?
[〜#〜]編集[〜#〜]
でApacheのETagを無効にする
Header unset ETag
キャッシュ動作をより予測可能にします...
これは 古いバグ のようであり、Header unset ETag
は違いをもたらします。
Apache 2.4.0+は、(ヘッダーに表示されるように)圧縮メソッド名をETagに自動的に追加し、304応答を防止します。
Mod_deflateの最新バージョンは、この動作を制御するために使用できる DeflateAlterETag をサポートしています。
DeflateAlterETag NoChange
これは少し奇妙なものとしてリクエストで目立ちます:
Cache-Control:max-age=0
しかし、おそらくもっと重要なのは、返されるコンテンツがhtmlであることに気づきました。動的に生成されていますか? Apacheは304応答を送信できますが、静的コンテンツを提供しているのでない限り、その呼び出しを行うのはApacheの仕事ではなく、アプリケーションロジックに依存します。例えば。ほとんどのphpアプリケーションは、そのようなものに対するサポートを制限しています。
キャッシュアプリは変更時間やetagなどをチェックできるため、フロントエンドキャッシュが役立つ場合がありますが、これは、アプリケーションとリクエストヘッダーの両方がキャッシュに対応している場合に限られます。たとえば、アプリケーションはコンテンツがキャッシュ可能であることを示すために適切なヘッダーを設定する必要があり、リクエストのCache-controlヘッダーのようなものはキャッシュを無効にします。ヘッダーはキャッシュフレンドリではありません。
ApacheがCache-Control:No-cache
で構成されている場合、ApacheはHTTP 304 Not modified
をクライアントに送信しません。
一部のリクエストを再検証する場合は、必要なページにのみCache-Control:No-cache
を配置します。すべてのリソースを再検証する必要はなく、そうすることで帯域幅を浪費しています。