我试图有一个关于我的caching策略的基本行为：文件应caching，并重新validation与服务器每次。 所以我希望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 （这是从铬devtools，取消选中禁用caching）
您可以看到响应包含Cache-Control：No-cache Header，并且If-modified-since标头匹配Last-modified标头。 ETag也匹配。
在这种情况下，Apache不应该发送一个304？
编辑
禁用apache中的ETags
Header unset ETag
使caching行为更可预测…
这似乎是一个古老的错误 ，解释了为什么Header unset ETag 。
Apache 2.4.0+会自动将压缩方法名称附加到ETag（如您的头文件中所示），并阻止304响应。
最新版本的mod_deflate支持一个DeflateAlterETag ，可以用来控制这个行为：
DeflateAlterETag NoChange
这个在请求中有点奇怪：
Cache-Control:max-age=0
可能更重要的是，我注意到，返回的内容是HTML。 它是dynamic生成的吗？ Apache可以发送一个304响应，但是除非你提供静态内容，否则这个调用不是Apache的工作，而是归结于你的应用逻辑。 例如，大多数PHP应用程序对此类事物的支持有限。
前端caching可能会有所帮助，因为caching应用程序可以检查修改时间，etag等，但前提是应用程序和请求标头都是caching友好的。 例如，应用程序必须设置适当的头文件来指示内容是可caching的，而像请求中的Cache-control头文件这样的东西将会否定caching。 您的标题不看caching友好。
如果Apacheconfiguration了Cache-Control:No-cache ，Apache将永远不会向客户端发送HTTP 304 Not modified的HTTP 304 Not modified 。
如果您想重新validation一些请求，请在您需要的页面上放置一个Cache-Control:No-cache 。 您不需要重新validation所有资源，并且这样做会浪费带宽。