13 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 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 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 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 transparency.

• 13.1 Client Interaction
  • 13.1.1 Cache Correctness
  • 13.1.2 Warnings
  • 13.1.3 Cache-control Mechanisms
  • 13.1.4 Explicit User Agent Warnings
  • 13.1.5 Exceptions to the Rules and Warnings
  • 13.1.6 Client-controlled Behavior
• 13.2 Expiration Model
  • 13.2.1 Server-Specified Expiration
  • 13.2.2 Heuristic Expiration
  • 13.2.3 Age Calculations
  • 13.2.4 Expiration Calculations
  • 13.2.5 Disambiguating Expiration Values
  • 13.2.6 Disambiguating Multiple Responses
• 13.3 Validation Model
  • 13.3.1 Last-modified Dates
  • 13.3.2 Entity Tag Cache Validators
  • 13.3.3 Weak and Strong Validators
  • 13.3.4 Rules for When to Use Entity Tags and Last-modified Dates
  • 13.3.5 Non-validating Conditionals
• 13.4 Response Cachability
• 13.5 Constructing Responses From Caches
  • 13.5.1 End-to-end and Hop-by-hop Headers
  • 13.5.2 Non-modifiable Headers
  • 13.5.3 Combining Headers
  • 13.5.4 Combining Byte Ranges
• 13.6 Caching Negotiated Responses
• 13.7 Shared and Non-Shared Caches
• 13.8 Errors or Incomplete Response Cache Behavior
• 13.9 Side Effects of GET and HEAD
• 13.10 Invalidation After Updates or Deletions
• 13.11 Write-Through Mandatory
• 13.12 Cache Replacement
• 13.13 History Lists