浏览器缓存和Ember数据

Question

我看到了一些有趣的Chrome行为，我需要一手解读正在发生的事情以及可能如何有效地解决它。

以下是该方案：

1. 用户查看资源列表（例如TODO项目）
2. 用户修改其中一些
3. 用户导航离开我的Ember应用程序，然后通过后退按钮返回
4. 用户查看以前的资源状态

在初始请求资源时，我发现这样的内容来自浏览器：

请求

Request Method:GET
Request URL:https://api.server/some_resource?ids%5B%5D=7495&ids%5B%5D=6420&ids%5B%5D=6787...
Status Code:200 OK
Accept:application/json, text/javascript, */*; q=0.01
Accept-Encoding:gzip,deflate
Accept-Language:en-US,en;q=0.8
If-None-Match:"(some md5)"
Referer:https://api.server
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2121.3 Safari/537.36
X-Requested-With:XMLHttpRequest

响应

Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Referer,Accept,Content-Type,Authorization
Access-Control-Allow-Methods:GET, POST, PUT, OPTIONS
Cache-Control:max-age=0, private, must-revalidate
Connection:keep-alive
Content-Encoding:gzip
Content-Type:application/json; charset=utf-8
Date:Tue, 12 Aug 2014 14:53:06 GMT
ETag:"(some md5 not matching If-None-Match)"
Server:nginx
Status:200 OK
Strict-Transport-Security:max-age=31536000
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:64b7607a-20a8-46f1-906e-0568bffffd15

返回查看资源时的后续请求：

请求

Request Method:GET
Request URL:https://api.server/some_resource?ids%5B%5D=7495&ids%5B%5D=6420&ids%5B%5D=6787...
Status Code:200 OK (from cache)
Accept:application/json, text/javascript, */*; q=0.01
Referer:https://api.server
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2121.3 Safari/537.36
X-Requested-With:XMLHttpRequest

响应

Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Referer,Accept,Content-Type,Authorization
Access-Control-Allow-Methods:GET, POST, PUT, OPTIONS
Cache-Control:max-age=0, private, must-revalidate
Content-Encoding:gzip
Content-Type:application/json; charset=utf-8
Date:Tue, 12 Aug 2014 14:53:06 GMT
ETag:"(same md5 as above for initial request)"
Server:nginx
Status:200 OK
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Request-Id:64b7607a-20a8-46f1-906e-0568bffffd15
X-Runtime:0.160730

请注意随后请求Chrome将状态报告为＆＃34; 200 OK（来自缓存）＆＃34;，这似乎是我发现这种情况的原因。

关于此问题的家庭作业在SO上出现了seemingly related个问题，而这个问题又链接到You Do Not Understand Browser History。好的，因此Chrome在使用后退按钮时无法验证etag。我该如何解决这个问题？禁用请求的缓存真的很糟糕，似乎应该有一个更优雅的解决方案。