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 cachedCache-Control: no-cache
, the response should not be cachedCache-Control: no-store
, the response should not be cachedCache-Control: must-revalidate
, the response should at least be verified, no such request in the servers logsPragma: 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.