同时具有gzip和Etag时无法缓存资源

Question

我试图在浏览器中缓存一个（javascript）资源，并在响应头中正确设置了所有的cache-control：max-age、Expires和Etag（如屏幕截图所示）。

浏览器使用“if-none-match”和“if-modified-since”进行请求，在这两种情况下都满足条件：

• if-modified-since=last-modified（文件从未更改过）
• 如果-none-match=Etag（同样，文件从未更改过）

所以我应该得到304回应，对吧？但不，我一直得到200 OK，这意味着apache每次都在为文件服务（尽管是压缩的）。用Firefox，Chrome，curl测试--没用。服务器总是为整个文件服务，即使我没有要求它...

使用curl,我将问题追溯到gzip和etag：

• 如果删除gzip（并从请求Etag中删除后缀-gzip）--一切正常:304
• 如果保留gzip并完全删除请求Etag--一切都很好:304
• 但如果保留'accept-encoding：gzip'和Etag,即使请求和响应Etag都相同（这次在末尾使用'-gzip'),服务器返回错误的200。感觉像是apache在gzipping失败之前比较了etag，确定它不匹配，然后提供gzipped文件，即使在gzip之后etag匹配。

以下是请求/响应：

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

请求标头00:09:12.000

• 用户代理:Mozilla/5.0(X11；Ubuntu；Linux i686；RV:36.0)Gecko/20100101 Firefox/36.0
• 如果-无匹配：“24e55-51138062CE6C0-Gzip”
• 如果-修改-自：Sat,2015年3月14日04:26:43 GMT
• 连接：保持活动状态
• 缓存控制：最大年龄=0
• 接受语言：en-US,en；q=0.5
• 接受编码：gzip,deflate
• 接受：/

响应标头？1100 ms

• Vary：Accept-Encoding
• 服务器:Apache/2.4.7(Ubuntu)
• 最后修改时间：Sat,2015年3月14日04:26:43 GMT
• 保持活动状态：timeout=5,max=100
• 过期时间：2015年3月25日星期三16:09:13 GMT
• ETAG：“24e55-51138062CE6C0-Gzip”
• 日期：2015年3月18日星期三16:09:13 GMT
• 内容类型:Application/JavaScript
• 内容-长度:53331
• 内容编码:gzip
• 连接：保持活动状态
• 缓存-控制：最大年龄=604800

Answer 1

一个尚未报告的解决办法是,您可以只应用以下配置：

RequestHeader edit "If-None-Match" '^"((.*)-gzip)"$' '"$1", "$2"'

（最初由Joost Dekeijzer建议，请参阅https://bz.apache.org/bugzilla/show_bug.cgi？id=45023#C22，目前仍适用于2.4版）

Answer 2

Apachemod_deflate正在为每个实体创建唯一的Etag，因为这些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>

如果您使用带有mod_deflate模块的Apache 2.5，则可以使用deflateAlteretag指令来指定在压缩响应时应如何更改ETag hader。

DeflateAlterETag AddSuffix|NoChange|Remove

来源:https://httpd.apache.org/docs/trunk/mod/mod_deflate.html#deflateAlteretag

这篇博文建议完全删除ETAG，并依赖于cache-control头。

在httpd.conf中执行此操作：

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

FileETag None

注意，如果mod_deflate的实体gzip:ed仍然携带与普通实体相同的ETag，这可能会导致ETag感知代理缓存的不一致。

更多信息请访问：

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