opkscale.blogg.se

This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.

However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. So why doesn't Chrome do this when using the back button?Ģ00 response (from cache) on pressing back button:ģ03 response on requesting the same page in a new tab: My understanding of no-cache (see here and here on SO) is that the browser must always revalidate all responses. I thought I could use max-age=0, no-cache as a lighter weight alternative to no-store where I don't want users seeing stale data via the back button (but where the data is non-valuable and so can be cached). See the screen captures below showing the output for the two different cases from the Network tab of the Chrome Developer Tools. If I open the same page, as I reached with the back button, in a new tab then it does check with the server (and gets a 303 See Other response as things have changed). However on pressing the back button the browser merrily hits its own cache without checking with the server.

I'm using Chrome 40 (so something nice and modern).Ĭache-Control: max-age=0, no-cache is set on all pages - so I expect the browser to only use something from its cache if it has first checked with the server and gotten a 304 Not Modified response.