启用 Rack::Deflater 时 ETag 发生变化答案

【问题标题】：ETag changes when Rack::Deflater is enabled启用 Rack::Deflater 时 ETag 发生变化
【发布时间】：2012-05-08 10:55:05
【问题描述】：

在启用 Rack::Deflater 压缩我的响应正文时，偶然发现了一些奇怪的东西。也许我遗漏了一些东西，但是启用此功能后，响应会被压缩，但是资源的 ETag 在每个请求上都会发生变化。这迫使应用程序每次都响应，而不是发送 304。这在没有启用 Rack::Deflater 的情况下有效，并且我已经验证页面源没有改变。我正在运行一个带有 Thin 作为 Web 服务器的 Rails 应用程序。

Gemfile.lock https://gist.github.com/2510816

有没有办法让我从机架中间件获得更多输出，以便我可以看到发生了什么？

提前致谢。

【问题讨论】：

标签： ruby-on-rails ruby http http-headers rack

【解决方案1】：

所以我已经解决了我原来的问题，但仍然没有得到想要的结果。原来 Rack::Deflater 需要在中间件堆栈中的 Rack::ETag 之前。仍然不确定为什么这会导致 ETag 更改每个请求，但如果我将 config.middleware.use "Rack::Deflater" 更改为 config.middleware.insert_before "Rack::ETag", "Rack::Deflater" 就足够了，那么 ETag 在请求之间变得一致。我仍然没有得到 304，但我认为那是因为不正确的缓存控制标头并且与原始问题无关。希望这对将来的某人有所帮助。

【讨论】：

FYI Rack::ETag 中间只是为它得到的任何东西创建标签。把它放在中间件堆栈中Rack::Deflater之后，它会尝试创建压缩数据的哈希，这是不正确的。
是的，这是有道理的，但即使它是从压缩数据生成的，如果输入数据和压缩数据没有改变，那么服务器生成的 ETag 不应该仍然保持不变.
只要算法是确定性的并且不添加任何来自外部的数据。你也不能指望。猜测一下，压缩是添加时间戳。或者也许随机化它的哈希函数。
找到了。 GzipWriter，这是 Rack::Deflater 使用的，它为它压缩的所有内容添加时间戳。
好吧，那就更有意义了。谢谢你的解释。