What HTTP headers are needed to let web browsers cache your server's dynamic content properly?

This article will tell you exactly what HTTP response headers you need to let web browsers know they should cache your web server's dynamic content properly. If you want to know what headers in the HTTP response are needed for HTTP clients to properly cache your HTTP server's dynamic webpages you've come to the right place.

If you want your resources cached by web browsers..

Your server should send the following cache control headers in the HTTP response if you want your resources cached by client browsers for a specified amount of time.

Header and Value	Supported HTTP Version	Explanation
Date: Tue, 24 Dec 2013 07:27:15 GMT	1.0 1.1	exact date of generating this response
Cache-Control: max-age=21600	1.1	how long you want it cached in seconds since date of access
Expires: Tue, 24 Dec 2013 13:27:15 GMT	1.0 1.1	when you want it expired

You need all of these headers to work for both HTTP/1.0-compliant and HTTP/1.1-compliant web browsers.

In this example, you want the web browser to cache the resource for 21600 seconds, or 6 hours, since the date of access. Suppose the date of access is Tue, 24 Dec 2013 07:27:15 GMT, then the resource should be expired at Tue, 24 Dec 2013 13:27:15 GMT, which is the same value of Expires header.

One fun question is how "date of access" is defined. Is it defined by the Date header in the response or is it defined by the web client's internal clock mechanism? Nobody on Google knows.

If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks.

So you want to add both Expires header and max-age directive. An HTTP/1.0 browser would understand Expires only. An HTTP/1.1 browser would understand both.

If you use a CDN, Expires and Cache-Control would let the CDN know when the CDN should grab a fresh copy from your server.

You cannot use Last-Modified or Etag header for this type of content because even if the script (e.g. a PHP script) has not been changed, the database content your script uses could've been changed. If you can guarantee that as long as your script remains the same the dynamic content generated by it is the same, you can treat the script as you treat any other static resources.

By definition, the ETag response-header field provides the current value of the entity tag for the requested resource. The Last-Modified entity-header field indicates the date and time at which the origin server believes the resource was last modified.

If you NEVER want your resources cached by web browsers..

Your server should send the following cache control headers in the HTTP response if you NEVER want your resources cached by client browsers.

Header and Value	Supported HTTP Version
Expires: Sat, 26 Jul 1997 05:00:00 GMT	1.0 1.1
Last-Modified: Tue, 24 Dec 2013 07:54:18 GMT	1.0 1.1
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0	1.1
Pragma: no-cache	1.0 1.1