13.1 Caching in HTTP


HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Because these elements are inextricable from other aspects of the protocol, and because they interact with each other, it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc.

Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see section 13.3).

Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches,

and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and might be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed
      - only by an explicit protocol-level request when relaxed by
        client or origin server
      - only with an explicit warning to the end user when relaxed by
        cache or client


Therefore, the HTTP/1.1 protocol provides these important elements:
      1. Protocol features that provide full semantic transparency when
         this is required by all parties.
      2. Protocol features that allow an origin server or user agent to
         explicitly request and control non-transparent operation.
      3. Protocol features that allow a cache to attach warnings to
         responses that do not preserve the requested approximation of
         semantic transparency.


A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency.
      Note: The server, cache, or client implementor might be faced with
      design decisions not explicitly discussed in this specification.
      If a decision might affect semantic transparency, the implementor
      ought to err on the side of maintaining transparency unless a
      careful and complete analysis shows significant benefits in
      breaking transparency.