当同时使用gzip和Etag时,无法缓存资源

Question

我正在尝试在浏览器中缓存(javascript)资源并正确设置响应标头中的所有Cache-control:max-age,Expires和Etag(如屏幕截图所示).

浏览器请求"if-none-match"和"if-modified-since",并且在这两种情况下满足条件:

• if-modified-since = last-modified(文件从未更改过)
• if-none-match = Etag(再次,文件从未更改过)

所以我应该得到回复304,对吗？但不,我一直得到200 OK,这意味着apache每次都会继续为文件服务(尽管是压缩的).经过Firefox,Chrome,curl测试 - 没用.服务器总是服务整个文件,即使我没有要求它...

使用curl,我已经将问题追溯到gzip和Etag:

• 如果我删除gzip(并从请求Etag中剪切后缀-gzip) - 一切都很好:304
• 如果我保留gzip并完全删除请求Etag - 一切都很好:304
• 但是如果我同时保留'accept-encoding:gzip'和Etag,即使请求和响应Etags都是相同的(这次最后使用'-gzip'),服务器返回错误的200.感觉就像apache比较ez之前的gzipping失败,决定它不匹配,然后提供gzip文件,即使在Etag匹配的gzip之后.

这是请求/响应:

• 请求方法:GET
• 状态代码: HTTP/1.1 200 OK

请求标题00:09:12.000

• User-Agent:Mozilla/5.0(X11; Ubuntu; Linux i686; rv:36.0)Gecko/20100101 Firefox/36.0
• 如果 - 无匹配:"24e55-51138062ce6c0-gzip"
• If-Modified-Since:星期六,2015年3月14日04:26:43 GMT
• 连接:保持活力
• 缓存控制:max-age = 0
• Accept-Language:en-US,en; q = 0.5
• Accept-Encoding:gzip,deflate
• 接受: /

响应标头Δ1100ms

• 变化:接受编码
• 服务器:Apache/2.4.7(Ubuntu)
• Last-Modified:周六,2015年3月14日04:26:43 GMT
• Keep-Alive:超时= 5,最大= 100
• 到期日:2015年3月25日星期三16:09:13 GMT
• Etag:"24e55-51138062ce6c0-gzip"
• 日期:2015年3月18日星期三16:09:13 GMT
• 内容类型:应用程序/ javascript
• 内容长度:53331
• 内容编码:gzip
• 连接:保持活力
• 缓存控制:max-age = 604800

Answer 1

Apache mod_deflate正在为每个实体创建唯一的Etag,因为它们标识了URL的特定实体变体.每个协商的变体都需要有独特的ETag:s.因为mod_deflate它就像将编码添加到已经计算的ETag一样简单.

一种解决方法是从Etag中删除编码:

<Location /js>
  RequestHeader  edit "If-None-Match" "^(.*)-gzip$" "$1"
  Header  edit "ETag" "^(.*[^g][^z][^i][^p])$" "$1-gzip"
</Location>

如果您将Apache 2.5与mod_deflate模块一起使用,则可以使用该指令DeflateAlterETag指定在压缩响应时如何更改ETag hader.

DeflateAlterETag AddSuffix|NoChange|Remove

资料来源:https://httpd.apache.org/docs/trunk/mod/mod_deflate.html#deflatealteretag

这篇博文建议完全删除Etags并依赖Cache-Control标题.

要做到这一点httpd.conf:

<IfModule mod_headers.c>
    Header unset ETag
</IfModule>

FileETag None

请注意,如果实体gzip:ed mod_deflate仍然带有与普通entiy相同的ETag,则可能导致ETag感知代理缓存中的不一致.

更多信息:

• https://bz.apache.org/bugzilla/show_bug.cgi?id=45023

Answer 2

我强烈怀疑Cache-Control: max-age=0是有问题的。

引用这篇文章及其优秀的答案：What's the Difference Between Cache-Control: max-age=0 and no-cache?

另一方面，使用 Cache-Control: no-cache（又名“端到端重新加载”）发送请求不会重新验证，并且服务器在响应时不得使用缓存副本。