I'm seeing some interesting Chrome behaviour, and I need a hand deciphering what's going on and possibly how to work around it effectively.
Here's the scenario:
- User views a list of resources (e.g. TODO items)
- User modifies a few of them
- User navigates away from my Ember application and then returns via the back button
- User sees previous state of resources
When making the initial request for the resources, I'm seeing something like this coming from the browser:
Request
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
Response
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
And the subsequent request when returning to view the resources:
Request
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
Response
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
Notice on the subsequent request that Chrome is reporting the status as "200 OK (from cache)", which seems to be why I'm seeing this happen.
My homework on this problem has turned up a seemingly related question on SO, which in turn links to You Do Not Understand Browser History. OK, so Chrome isn't validating the etag when the back button is used. How do I work around this? Disabling caching of requests really sucks, and it seems like there should be a more elegant solution.
