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

Question

我正在尝试在浏览器中缓存一个 (javascript) 资源，并在响应 header 中正确设置所有 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，即使请求和响应 Etag 相同(这次末尾带有“-gzip”)，服务器也会返回错误的 200。它感觉就像 apache 在 gzip 失败之前比较 etag，决定它不匹配，然后提供 gzip 文件，即使在 gzip 之后 Etag 匹配。

这是请求/响应:

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

请求 header 00:09:12.000

• 用户代理:Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:36.0)壁虎/20100101 Firefox/36.0
• If-None-Match:“24e55-51138062ce6c0-gzip”
• If-Modified-Since:2015 年 3 月 14 日星期六 04:26:43 GMT
• 连接:保持事件状态
• 缓存控制:max-age=0
• 接受语言:en-US,en;q=0.5
• 接受编码:gzip、deflate
• 接受:/

响应 header Δ1100ms

• 变化:接受编码
• 服务器:Apache/2.4.7 (Ubuntu)
• 最后修改时间:2015 年 3 月 14 日星期六 04:26:43 GMT
• 保持事件状态:超时=5，最大值=100
• 过期时间:2015 年 3 月 25 日星期三 16:09:13 GMT
• 电子标签:“24e55-51138062ce6c0-gzip”
• 日期:2015 年 3 月 18 日星期三 16:09:13 GMT
• 内容类型:application/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 处理器。

DeflateAlterETag AddSuffix|NoChange|Remove

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

这blog post建议完全删除 Etags 并依赖 Cache-Control header 。

在 httpd.conf 中执行此操作:

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

FileETag None

请注意，如果由 mod_deflate 压缩的实体仍然带有与普通实体相同的 ETag，这可能会导致 ETag 感知代理缓存不一致。

更多信息在这里:

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