I am sending validly formatted HTTP response "Expired" headers (e.g. "Wed, 04 May 2011 09:29:09 GMT") with a page served through https://[host]:{port}/ (with [host] being localhost) from a J2EE application, using response.setDateHeader("Expires", {milliseconds a few seconds in the future} ).
On my pages I have a link to the same page. When I click this link from within Firefox (4) or IE (8), the page is reloaded from cache until the Expired time is reached. Once the Expired time is passed, clicking on the same link results in the page being loaded from the server with fresh data. If I hit F5 on either of the mentioned browsers, the page is reloaded with new data from the server (Firebug shows me that Cache-Control: max-age=0 is being sent with the request).
With Google Chrome, both F5 and clicking on the link have the same effect. The page is ALWAYS reloaded from the server with new data.
I was unable to find any well documented explanation of this effect.
Does any one know why in my case Google Chrome is not respecting the "Expired" headers the server is sending with the page responses and thus ALWAYS requesting the data from the server?
The way chrome works in this respect can cause extreme confusion. It seems that pressing F5 or "reload this page" simply prevents chrome from serving a request from the cache. This is easily compared with pressing enter in the url window, where it will use the cache, even though in both cases the request header (which doesn't get sent anywhere) has Cache-Control: max-age=0.
If you press ctrl+F5 you get Cache-Control: no-cache. I think the difference between F5 & ctrl+F5 is that both will result in a request being sent to the server, but in the ctrl+F5 case the server should know to not respond with a 304 not modified.
来源：https://stackoverflow.com/questions/5881408/why-does-google-chrome-not-use-cached-pages-when-i-define-the-http-expires-hea