Full page reload on Post/Redirect/Get ignoring cache control

Question

I have a page that loads a lot of images, css and javascript. I\'ve added a far future Expires header and set Cache-Control to public on these external dependencies so they

Answer 1

The fix: cache-control: no-store

(You may also want to use status code 307 instead of 302, which will preserve the method.)

The solution was found—after many days of frustration—in a comment on this open WebKit bug:

CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.

Answer 2

F5 reloads all the page's resources in some browsers, so they ignore the cache headers and ask for every resource again.

If you want to "cache" POST pages you have to convert those pages in static resources, i.e. generating a .html file from the .php for example and then serve the .html as a static resource.

This is valid ONLY if the content of the page doesn't change

Answer 3

When you F5/refresh in Chrome, Safari or IE8 all the GET resources are requested again, even if they've been cached.

If you watch the request/response with the dev tools or Fiddler you'll see that the server responds with an HTTP 304 status and no content. This tells the browser that they don't need to download it again and that they can continue to use the cache.

In Chrome's dev tools' Resource tab files refreshed like that will have a latency time, but a download time of 0ms.

If you reload the page by leaving and returning you'll find that these cached files are not retrieved again and the server is not checked.

This behaviour of F5/refresh for GET static resource is correct - it's FX and IE6 that are doing it wrong. It also helps with the confusing CTRL+F5 command that most users don't know about.

You can't cache POST or pages that return a temporary HTTP redirect:

POST changes data and should always prompt before being sent again, and its results are never cached.

Redirects are handled at a low level in the HTTP stuff - below caching. Really it tells the browser to get the resource from somewhere else and while it can cache that it hasn't cached the redirect and needs to check again.

You should be able to cache a 301 permanent redirect, but a 302 or 303 temporary redirects shouldn't be cached according to the HTTP spec.