问题
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 should be cached. But every time I do a Post/Redirect/Get chrome tries to load these again. This behavior is very similar to reloading the page. I've added ETags and handle the If-None-Match header which helps a bit, but it still generates too many useless requests.
How do I tell chrome and safari to get the files from cache?
chrome NOK
safari NOK
firefox OK
ie OK
Also see Full page reload on Post/Redirect/Get ignoring cache control on the google support forum.
Clarification:
I don't want the browser to request image1.png twice. It should be cached.
200 GET page1.html
200 GET image1.png (Cache-Control: public, Expires and ETag)
302 POST action.asp (form submitted from page1.html, redirects)
200 GET page2.html
304 GET image1.png (If-None-Match)
Example:
I've created a simple example to illustrate the problem.
http://crydust.be/lab/prg/
Headers:
The headers I send with the image are:
HTTP/1.1 200 OK
Date: Fri, 18 Jun 2010 11:30:22 GMT
Server: Apache
Cache-Control: public, max-age=86400
Expires: Sat, 19 Jun 2010 11:30:24 GMT
Etag: "123"
Content-Length: 866
Content-Type: image/png
Which should make it cached for 24 hours. There is no Vary: * or anything like that.
Update: This behavior is now also present in Safari Mobile on iOS 4. A horible regression in page-load speed.
Update: There is a bugreport about this issue in the webkit bugzilla. Bug 38690 - Submitting a POST that leads to a server redirect causes all cached items to redownload
Update: The problem persists on iOS 4.0.1
Update: The problem persists on iOS 4.1
Update: The problem persists on iOS 4.2
Update: The problem persists on iOS 4.2.1 and in Chrome from version 6 till 9.
Update: There is a bugreport about this issue in the Chromium project. (you can star it to show you care) Issue 68621: Post/Redirect/Get ignoring cache instructions
Update: The problem persists on Chrome from version 6 till 10. It is now a 9 months old bug.
Update: The problem is fixed as of 2011-03-21 19:33:07 PST. This is reflected in the behavior of chrome 12 (canary).
回答1:
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.
回答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
回答3:
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.
来源：https://stackoverflow.com/questions/3004702/full-page-reload-on-post-redirect-get-ignoring-cache-control