11

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
  • 11,768
  • 7
  • 68
  • 102
  • 1
    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
  • 1
    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

14

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,950
  • 3
  • 35
  • 58
  • 3
    With this comment, you have gifted me a Friday evening, for that I say "thank you".. – Vivek Chandra Aug 28 '20 at 07:34
  • 1
    Thank you, @SamuelHapak - I've been wrestling with Safari's aggressive caching (more aggressive than all the other browsers, it appears), trying all sorts of variations of the `Cache-Control:` header (`no-store, max-age=0, must-revalidate` etc.) but, until I read your answer above, I was unaware of the `Vary:` header and the power of `Vary: *` to override all other client assumptions and **insist** that the resource being requested _must_ be fetched from the origin server. – Rounin Sep 30 '21 at 09:11
  • 1
    Does anyone know which specific header value (for `Vary`) is actually making Safari not cache the page? The service I'm using to host my app won't let me do `Vary: *` for whatever reason. – ffxsam May 19 '22 at 03:03
  • This solved my caching issue for macos and ios safari in my cctv project. My specific use case was using a html video element and setting the poster to a url of a dynamically generated jpeg before loading live streaming fragmented mp4. Thanks. – kevinGodell Aug 13 '22 at 12:31