Menu
I'd like an HTTP response to expire 24 hours from now (meaning the browser won't make any requests for that URL until tomorrow). But, if the request is re-issued tomorrow after expiration, I want to make sure the browser will send the right request headers so that the server will send a 304 instead of forcing the client to re-download the whole response body if it hasn't changed on the server. And I'd like that 304 to also expire 24 hours later.
First, is this sccenario possible? Or do I have to choose between Expiration-style caching and 304-style caching, but not both? If it is possible, what are the right response headers (both for the initial response and for the subsequent 304s) which will make it happen?
If as often happens, the answer varies based on browser type/version, then which headers work for which browsers-- and which browsers won't be able to do what I want at all? I'm only interested in the most common browsers in use today (e.g. IE6+, FF3+, Chrome latest, Safari latest)?
Apologies if this answer has already been asked on SO-- I searched for a while and came up blank.
CLARIFICATION: I'm asking this question because I'm putting together an automated test suite to verify, regardless of server platform, that a web app is generating the correct HTTP headers to generate the client-caching behavior we want all our web apps to have. So I'm not interested (at least for now) in how to configure Apache/IIS/PHP/Rails/Django/JSP/ASP.NET/etc. to generate the right headers. I simply want to know, at the HTTP layer only, what the right headers are.
UPDATE: I found this SO question which answers part of my question. According to RFC 2616 10.3.5, it says, I should include an Expires: or Cache-Control: max-age headers to the 304s returned by the server. This is definitely the desired behavior.
What that question doesn't answer, however, is whether this RFC-compliant approach will work on existing popular browsers, especially IE6/7/8 which are the usual standards-compliance culprits, but also IE9, FF4+, latest Chrome, and latest Safari which our application also must support. If any of those browsers don't behave as the RFC mandates, are there workarounds I can use?
291
The response-header fields allow the server to pass additional information about the response which cannot be placed in the Status- Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
Request headers contain more information about the resource to be fetched, or about the client requesting the resource. Response headers hold additional information about the response, like its location or about the server providing it.
A response header is an HTTP header that can be used in an HTTP response and that doesn't relate to the content of the message. Response headers, like Age , Location or Server are used to give a more detailed context of the response.
Send an ETAG header so that the client may make a conditional HTTP request to revalidate a response after its freshness lifetime has expired.
Send a Cache-Control: max-age or Expires directive to specify when you want the resource to expire.
Avoid using a Vary header or any directive that forbids caching.
These directives will work in all popular browsers (IE6+, Firefox, Chrome) except for Safari on Windows, which alone lacks a persistent HTTP cache that works across multiple sessions.
http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx explains what happens when you fail to provide proper caching headers.
Fiddler's Caching response inspector will help you understand how a given response will be cached.
135
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
