title: Browser Cache, and Ember Data
body: <p>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.</p>
  
  <p>Here's the scenario:</p>
  
  <ol>
  <li>User views a list of resources (e.g. TODO items)</li>
  <li>User modifies a few of them</li>
  <li>User navigates away from my Ember application and then returns via the back button</li>
  <li>User sees previous state of resources</li>
  </ol>
  
  <p>When making the initial request for the resources, I'm seeing something like this coming from the browser:</p>
  
  <h2>Request</h2>
  
  <pre><code>Request Method:GET
  Request URL:https://api.server/some_resource?ids%5B%5D=7495&amp;ids%5B%5D=6420&amp;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
  </code></pre>
  
  <h2>Response</h2>
  
  <pre><code>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
  </code></pre>
  
  <p>And the subsequent request when returning to view the resources:</p>
  
  <h2>Request</h2>
  
  <pre><code>Request Method:GET
  Request URL:https://api.server/some_resource?ids%5B%5D=7495&amp;ids%5B%5D=6420&amp;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
  </code></pre>
  
  <h2>Response</h2>
  
  <pre><code>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
  </code></pre>
  
  <p>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.</p>
  
  <p>My homework on this problem has turned up a <a href="https://stackoverflow.com/questions/16173322/google-chrome-does-not-revalidate-etag-on-back-forth">seemingly related</a> question on SO, which in turn links to <a href="http://madhatted.com/2013/6/16/you-do-not-understand-browser-history" rel="nofollow noreferrer">You Do Not Understand Browser History</a>. 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.</p>