Home > Articles

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Client Page Caching

A common mechanism for improving Web client and server performance is for the client to cache Web pages locally and only reload the Web page if the local cached copy is out of date. There are two mechanisms used for caching:

  • Store the Web page Last-Modified date with the page contents.

  • Store the ETag header value (if provided) with the page contents.

The Last-Modified and ETag values are supplied by the server as response header fields; HTTP 1.1–compliant servers should return both fields if at all possible. The Web server takes care of these values for static HTML pages, but you should attempt to provide them for any servlets you develop (see Chapter 7). If neither of these header fields are defined in the response, the client cannot keep a local cache copy of the page, and must always retrieve the page from the server. For many servlets, this will be a necessary requirement, as the servlet page contents will be dynamic and unsuitable for caching by the Web client.

A browser can request that a page only be provided if it isn't in the local cache using the following headers:

Header Field

Description

If-Modified-Since

Defines the date of the cached copy of the page.

If-None-Match

Defines the Entity Tag for the cached copy of the page.


If the date or ETag in the request matches the server's copy of the page, a server might return a response of 304 "Not Modified" rather than return the page body. Usually only one of these fields will be specified, but if both are defined in a request, both values must be unchanged for the server to reply with the 304 response.

The ETag value is generated by a server to enable more reliable validation of cached Web pages in cases where it is inconvenient to store modification dates, or where the server wants to avoid problems that might arise from using the modification date.

  • + Share This
  • 🔖 Save To Your Account