在 Chrome/Safari 中没有得到 304 响应，但通过 curl答案

【问题标题】：Getting no 304 response in Chrome/Safari but via curl在 Chrome/Safari 中没有得到 304 响应，但通过 curl
【发布时间】：2016-01-29 16:35:19
【问题描述】：

我遇到了一个奇怪的问题，而且我的想法已经不多了。在我的 Rails(4.2)-App 中，我使用 fresh_when-Method 使我的博客页面的客户端缓存无效：

def show
  @post = Post.find(params[:id])
  fresh_when @post
end

使用 curl 一切正常，发送匹配的 Etag 会给我一个 304 响应：

celmare$ curl -i -H 'If-None-Match: "3b4dd96aac692c03ce623db459c9cef2"' https://grosse.io/blog

回复：

HTTP/1.1 304 Not Modified
Connection: keep-alive
Status: 304 Not Modified
Last-Modified: Sun, 04 Oct 2015 10:41:08 GMT
Cache-Control: max-age=0, private, must-revalidate
Strict-Transport-Security: max-age=31536000
X-XSS-Protection: 1; mode=block
X-Request-Id: 68a0ecd2-3fac-4004-ac1e-fd6d14780f61
ETag: "3b4dd96aac692c03ce623db459c9cef2"
X-Frame-Options: SAMEORIGIN
X-Runtime: 0.006207
X-Content-Type-Options: nosniff
Date: Thu, 29 Oct 2015 13:17:02 GMT
X-Powered-By: Phusion Passenger 5.0.15
Server: nginx/1.8.0 + Phusion Passenger 5.0.15

当我在浏览器中打开页面时（例如 Chrome 版本 47.0.2526.35 beta（64 位）），尽管 Etag 仍然匹配，但我总是得到 200：

请求标头：

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Connection:keep-alive
Cookie:_gat=1; _syscfg_net_v2_session=eGFlYk83Z0kwUE9IYmtUVHg1Z1ppbHF2eFBrUitiTDBsRG1Kbml2bW8vQVZ6YW4xM0ZuRTNOS0w2VmVLM1ZaN0czZno3N0Y2MWpiUWNjQUV0YkVlaXhCZUJyZlJWWEVIZVpPclFaaHZxdFNncjNBVVg3MFR2SE0yWDRUaklsSlRMbmw4OVQrQmlDRHBIbmRSMS9VVml3PT0tLTYvUGdURTRaRjNXSU9WOTdOY1F3OEE9PQ%3D%3D--3bafbda7d522c61cd9fd04898c2c6a4bac06131b; _ga=GA1.2.235147781.1445350582
Host:grosse.io
If-Modified-Since:Sun, 04 Oct 2015 10:41:08 GMT
If-None-Match:W/"3b4dd96aac692c03ce623db459c9cef2"
Referer:https://grosse.io/blog
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.35 Safari/537.36

响应标头：

Cache-Control:max-age=0, private, must-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html; charset=utf-8
Date:Thu, 29 Oct 2015 13:16:48 GMT
ETag:W/"3b4dd96aac692c03ce623db459c9cef2"
Last-Modified:Sun, 04 Oct 2015 10:41:08 GMT
Server:nginx/1.8.0 + Phusion Passenger 5.0.15
Set-Cookie:_syscfg_net_v2_session=MUtjWlQyY1ZFZnF2TzlvTDJkdnpmMDhqVmhoVld5YkJDdHl5NUtIdXJTY1VZQ1AzV1NVMjF1alFDSE9NKzliOGhzcmc4S3FLajRmNGFZUjltQzdPNDg4SW51aUxGU2xDd0FxVi82UFZneE5YU1FnTjJVSFhpL3RCQkNYdjlFVTlyZVRRU0ZPdG83UFNVbjVyckJmZ0R3PT0tLXh4Zzg0cjhBSTZKbVpkayttanpwUFE9PQ%3D%3D--dc404af2428a17085bea4b40a3f4f0fc6ef01e50; path=/; secure; HttpOnly
Status:200 OK
Strict-Transport-Security:max-age=31536000
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Powered-By:Phusion Passenger 5.0.15
X-Request-Id:0633095f-b95d-4339-8e62-8b15683c2d8c
X-Runtime:0.034172
X-XSS-Protection:1; mode=block

最重要的是：在我的本地环境中，它使用同一个浏览器。我几乎无法想象这是 NGINX 的事情，因为一切都配置得很默认。会不会是 HTTPS 的问题？

有什么想法吗？提前致谢。

【问题讨论】：

标签： ruby-on-rails caching nginx http-headers

【解决方案1】：

好的，我找到了原因。 NGINX 的 gzip 压缩与弱的“W/”Etag 相结合是一个问题。将尝试升级 NGINX 或使用补丁。

在 nginx.conf 中的 gzip on; 之后添加 etag on; 修复了 1.7.4 及更高版本的问题。

【讨论】：