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 may 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
Therefore, the HTTP/1.1 protocol provides these important elements:
Protocol features that provide full semantic transparency when this
is required by all parties.
Protocol features that allow an origin server or user agent to
explicitly request and control non-transparent operation.
Protocol features that allow a cache to attach warnings to
responses that do not preserve the requested approximation of
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 implementer may be faced with
design decisions not explicitly discussed in this specification. If
a decision may affect semantic transparency, the implementer ought
to err on the side of maintaining transparency unless a careful and
complete analysis shows significant benefits in breaking