How to optimize with Last-Modified and Cache-Control?
Last Modified header
Section 14.29 of RFC2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] describes the last-modified header. If this header is sent with a response containing content, then the client is able to cache that content and check that it is up to date with a request containing a If-Modified-Since header.
If the content has not been modified, then a simple 304 response may be sent and the server can avoid resending the content.
Jetty will put a last-modified-header on all static content served and implements support for the if-modified-since header in the default servlet that serves that static content. For dynamic content generated by servlets, last-modified and if-modified-since may be supported by implementing the getLastModified(request) method on the servlet.
Even with a last-modified header, the client needs to issue a if-modified-since request to verify that the contents of it's cache are up to date. These extra requests can be avoided altogether by sending cache-control headers in the response that tell the client how long the content can be held for, if it can be shared between users or if it can be cached at all.
Section 14.9 of RFC2616|http://www.w3.org/Protocols/rfc2616/rfc2616.html] describes the cache control header in detail. The Jetty default servlet allows the cache control header to be set for static content by using the cacheControl init parameter. For example,
if the init paramters for the default servlet included:
<init-param> <param-name>cacheControl</param-name> <param-value>max-age=3600,public</param-value> </init-param>
then static content would be cached for up to hour and shared between all users, without checking the server.