Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

How to optimize with Last-Modified and Cache-Control?

Last Modified header

Section 14.29 of RFC2616|] 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|] 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:

Code Block

then static content would be cached for up to hour and shared between all users, without checking the server.

Back to Jetty Documentation

Contact the core Jetty developers at
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery