6

A response from the server to a GET request has the following headers:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Pragma: no-cache
Date: Thu, 08 Feb 2018 19:16:26 GMT
Cache-Control: no-cache, no-store, must-revalidate
Server: Microsoft-IIS/10.0
Content-Length: 801
Expires: -1
Content-Encoding: deflate
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 5.2

Now 4 seconds later the browser (macOS Safari 11.0.3) makes the same request. The developer consoles shows that the response is served from the cache. I'm not understanding why Safari is even caching the response:

  • Expires is an invalid value, the response should not be cached
  • Cache-Control: no-cache, the response should not be cached
  • Cache-Control: no-store, the response should not be cached
  • Cache-Control: must-revalidate, the response should at least be verified, no such request in the servers logs
  • Pragma: no-cache, the response should not be cached

So despite all the headers being explicit on whether the response should be cached, Safari chooses to cache the response. Why?

For completeness, the request looks like this:

GET (...) HTTP/1.1
Host: (...)
Referer: (...)
Accept: application/json, text/javascript, */*; q=0.01
Connection: keep-alive
Accept-Encoding: br, gzip, deflate
Accept-Language: en-us
DNT: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/604.5.6 (KHTML, like Gecko) Version/11.0.3 Safari/604.5.6
Cookie: (...)
X-Requested-With: XMLHttpRequest

I just found out that in the web inspector Cached: "Yes (disk)", doesn't relate to whether the response was retrieved from the cache or the web server. There were some requests that showed up with "Yes (disk)", while they also showed up in the server logs.

Bouke
  • 10,025
  • 6
  • 49
  • 88
  • I did find a reported bug for webkit that might explain this; https://bugs.webkit.org/show_bug.cgi?id=170714. Possibly even this bug report from 2011: https://bugs.webkit.org/show_bug.cgi?id=62250. – Bouke Mar 05 '18 at 20:39
  • Related question, possibly limited to localhost: https://stackoverflow.com/questions/46525065/safari-11-x-xsrf-token-not-updated-after-refresh. – Bouke Mar 06 '18 at 07:34
  • This is possibly `Safari` bug (or feature) - there are a lot of similar issues with it. As a workaround you can use random parameters in `URL` as described here https://stackoverflow.com/questions/9948545/how-to-disable-ajax-caching-in-safari-browser. Also take a look at this SO discussion: https://stackoverflow.com/questions/12506897/is-safari-on-ios-6-caching-ajax-results – SergeyLebedev Mar 10 '18 at 21:31
  • Have you seen this post https://stackoverflow.com/questions/49547/how-to-control-web-page-caching-across-all-browsers?answertab=active#tab-top – Simon Franzen Mar 11 '18 at 15:40
  • You did empty the cache before testing right? (there is no old cached version) ... I have seen similar strangeness in Safari. – user1133275 Mar 12 '18 at 10:20
  • I just found that "Cached: Yes (disk)" still (might) hit the server. So I'm not sure what to make of that column even. Could it be related to "must-revalidate", and the request to the server is revalidating? So what response am I getting in my ajax call, I suppose that would be the revalidated (updated) response? – Bouke Mar 14 '18 at 08:03

1 Answers1

6

I've had a similar problem (see Safari Caching GET request even with disabled cache). Adding Vary: * forced Safari to stop caching. Nothing else worked, including Vary: Cookie even though cookies changed between requests.

This answer helped me: https://stackoverflow.com/a/2068353/1364158

Samuel Hapak
  • 6,423
  • 2
  • 30
  • 54