I know that SEDE query results are cached on the server side. I wonder if in some cases they are also cached on the client side.
asked Apr 19 at 21:51
Add a comment
|
1 Answer
I wonder if in some cases they are also cached on the client side.
I'm no HTTP caching expert, but technically maybe yes? (as in- they could be in a standards-conforming user-agent / client software). The server responds with Cache-Control: private (client-side cache) (presumably because it uses IIS, and that's the default value for IIS (see this and this)). It doesn't set max-age, or the Expires header (I.e. no explicit expiration times), or the Last-Modified header. Neither does it send ETags. I don't know if it does anything with If-Modified-Since or If-None-Match in requests. So that leaves client freshness heuristics (see also related RFC and related MDN), which are implementation-defined. In practice, see What heuristics do browsers use to cache resources not explicitly set to be cachable?.
Though technically if you count specific cases with specific user-agents like browser history navigation, mechanisms like browser back-forward cache are caches too (see related web.dev and related MDN), so there's that.
Given the current, predictable schedule for SEDE refreshes though, I (naively) don't see a reason not to specify expiration times, as long as each query has a unique URLs for its various result set resources / API endpoints (which I'm pretty sure it does- unique queries have unique IDs), or uses some other mechanism like custom HTTP header + Vary header. Again, I'm no expert in this topic. Maybe everything I'm saying is nonsense.
If you want to know if your browser is caching the resource, open devtools, go to the network tab, make sure any cache-disabling feature is disabled, click the "Run Query" button, find the request that corresponds to the response with the data, and look for an indication that the response was retrieved from a cache (Ex. the size column in Chromium devtools).