The first header Cache-Control: must-revalidate means that browser must send validation request every time even if there is already cache entry exists for this object.
Browser receives the content and stores it in the cache along with the last modified value.
Next time browser will send additional header:
If-Modified-Since: 15 Sep 2008 17:43:00 GMT

This header means that browser has cache entry that was last changed 17:43.
Then server will compare the time with last modified time of actual content and if it was changed server will send the whole updated object along with new Last-Modified value.

If there were no changes since the previous request then there will be short empty-body answer:
HTTP/1.x 304 Not Modified

And browser will use the cached content.

What if server doesn’t send Cache-Control: must-revalidate?
Then modern browsers look at profile setting or decide on their own whether to send conditional request. So we better to send Cache-Control to make sure that browser sends conditional request.

Sample PHP code:

$last_modified_ts = floor(mktime()/30)*30;
if (
isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) &&
strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) >= $last_modified_ts
)
{
header('HTTP/1.1 304 Not Modified');
exit;
}
header('Cache-Control: must-revalidate');
header('Last-Modified: '.gmdate('d M Y H:i:s',$last_modified_ts).' GMT');
echo date('d M Y H:i:s');


This example outputs cached datetime that’s expiring every 30 seconds.

Last-Modified suits good in case we can easily calculate modification time of page content.

We must be careful with Last-Modified if we have page content that consists many fragments. We should calculate Last-Modified value of every fragment and get the latest one.
Note that if we have authentication and there is a page fragment that depends on authentication we have to reset Last-Modified value after login/logout – for every page that contains the fragment.
Also note that in case of several web servers we should make sure that Last-Modified value changes synchronous for all the servers.

ETag
This method suits for cases when it’s difficult to maintain Last-Modified value: when you have complicated application with many page fragments especially if there are third-party libraries. Or for the case with authentication, when page content depends on authentication info.
There is simple idea besides ETag:
ETag value depends on the content and must be different for different content and the same for the same content.

Sample usage of ETag header:
$content = floor(mktime()/30)*30;
$etag = md5($content);
if (isset($_SERVER['HTTP_IF_NONE_MATCH']) && $_SERVER['HTTP_IF_NONE_MATCH'] == $etag)
{
header('HTTP/1.1 304 Not Modified');
exit;
}
header('Cache-Control: must-revalidate');
header('ETag: '.$etag);
echo $content;
echo '
Request time: '.date('d M Y H:i:s');


In this example content changes every 30 seconds and browsers will download only if the content was changed.

Static Content and Unnecessary ETag Header
For static content it’s recommended to send Cache-Control: max-age=… header with higher max-age value. In this case browser won’t send any request on normal page views.
So for static content there is no use of ETag header.
The worse case is in case of web servers cluster as ETag value differs for the file on different servers.
For Lighttpd server you can disable Etag using
static-file.etags = 'disable'
in lighttpd.conf

Disabling ETag in Apache:
Header unset ETag
FileETag None

Note that we still want Last-Modified header for static files. If user presses Refresh button, then browser will send conditional request and server will respond “304 Not Modified”.
And if you disable both Last-Modified and ETag browser will have to download the whole content again when user presses Refresh.

Lighttpd and Apache will send Last-Modified if you have configured mod_expires.

For Lighttpd there is mod_expire module. Enable it in server.modules section:
server.modules = (
...
"mod_expire",
...
)
Then add following directives for directories with static files:
$HTTP["url"] =~ "^/images/" {
expire.url = ( "" => "access 30 days" )
}


Max-age for Nginx server can be enabled using ngx_http_headers_module:
expires max;

Now web server sends the caching header for static files:
Cache-Control: max-age=2592000

In case of design change we should prevent using outdated content that browsers have in their caches. This can be done by adding file versions to filenames:
script.js -> script1.js -> script2.js -> ... etc

Cache-control: max-age can be useful also when we output HTML. Imagine pages generated by PHP that changed not so often, once per day or even longer. But browsers still have to download HTML every page view.
We can improve it by sending max-age value in PHP.
header('Cache-Control: max-age=28800');

This way we set desirable cache lifetime to 8 hours. Now if someone is clicking a link for second time within 8 hours period he gets the page instantly.

Max-age also helps to make proxy servers more efficient. We can easily organize transparent server-side caching by adding proxy server to web frontend.

Note that there is not easy case if pages have content that changes often and that’s relevant.
For example, there can be difficulties in caching pages with login form that transforms into some box with «Hello username» after user login or if there are user comments, the user who posted commentary will not see it. Because we cannot ask browser to destroy cache entry, it will still get the old page from cache.
The solution can be using Javascript to generate login box (requires enabled Javascript). If we set a cookie after user logged in, we can check it on client-side and generate suitable content for the logged in user. This way the content will be the same from server side view and can be cached.