rfc 2616

• fielding, et al. standards track [page 71]
  
  rfc 2616 http/1.1 june 1999
  
  any response containing an entity-body may be subject to negotiation,
  including error responses.
  
  there are two kinds of content negotiation which are possible in
  http: server-driven and agent-driven negotiation. these two kinds of
  negotiation are orthogonal and thus may be used separately or in
  combination. one method of combination, referred to as transparent
  negotiation, occurs when a cache uses the agent-driven negotiation
  information provided by the origin server in order to provide
  server-driven negotiation for subsequent requests.
  
  12.1 server-driven negotiation
  
  if the selection of the best representation for a response is made by
  an algorithm located at the server, it is called server-driven
  negotiation. selection is based on the available representations of
  the response (the dimensions over which it can vary; e.g. language,
  content-coding, etc.) and the contents of particular header fields in
  the request message or on other information pertaining to the request
  (such as the network address of the client).
  
  server-driven negotiation is advantageous when the algorithm for
  selecting from among the available representations is difficult to
  describe to the user agent, or when the server desires to send its
  "best guess" to the client along with the first response (hoping to
  avoid the round-trip delay of a subsequent request if the "best
  guess" is good enough for the user). in order to improve the server's
  guess, the user agent may include request header fields (accept,
  accept-language, accept-encoding, etc.) which describe its
  preferences for such a response.
  
  server-driven negotiation has disadvantages:
  
  1. it is impossible for the server to accurately determine what
  might be "best" for any given user, since that would require
  complete knowledge of both the capabilities of the user agent
  and the intended use for the response (e.g., does the user want
  to view it on screen or print it on paper?).
  
  2. having the user agent describe its capabilities in every
  request can be both very inefficient (given that only a small
  percentage of responses have multiple representations) and a
  potential violation of the user's privacy.
  
  3. it complicates the implementation of an origin server and the
  algorithms for generating responses to a request.
  
  fielding, et al. standards track [page 72]
  
  rfc 2616 http/1.1 june 1999
  
  4. it may limit a public cache's ability to use the same response
  for multiple user's requests.
  
  http/1.1 includes the following request-header fields for enabling
  server-driven negotiation through description of user agent
  capabilities and user preferences: accept (section 14.1), accept-
  charset (section 14.2), accept-encoding (section 14.3), accept-
  language (section 14.4), and user-agent (section 14.43). however, an
  origin server is not limited to these dimensions and may vary the
  response based on any aspect of the request, including information
  outside the request-header fields or within extension header fields
  not defined by this specification.
  
  the vary header field can be used to express the parameters the
  server uses to select a representation that is subject to server-
  driven negotiation. see section 13.6 for use of the vary header field
  by caches and section 14.44 for use of the vary header field by
  servers.
  
  12.2 agent-driven negotiation
  
  with agent-driven negotiation, selection of the best representation
  for a response is performed by the user agent after receiving an
  initial response from the origin server. selection is based on a list
  of the available representations of the response included within the
  header fields or entity-body of the initial response, with each
  representation identified by its own uri. selection from among the
  representations may be performed automatically (if the user agent is
  capable of doing so) or manually by the user selecting from a
  generated (possibly hypertext) menu.
  
  agent-driven negotiation is advantageous when the response would vary
  over commonly-used dimensions (such as type, language, or encoding),
  when the origin server is unable to determine a user agent's
  capabilities from examining the request, and generally when public
  caches are used to distribute server load and reduce network usage.
  
  agent-driven negotiation suffers from the disadvantage of needing a
  second request to obtain the best alternate representation. this
  second request is only efficient when caching is used. in addition,
  this specification does not define any mechanism for supporting
  automatic selection, though it also does not prevent any such
  mechanism from being developed as an extension and used within
  http/1.1.
  
  fielding, et al. standards track [page 73]
  
  rfc 2616 http/1.1 june 1999
  
  http/1.1 defines the 300 (multiple choices) and 406 (not acceptable)
  status codes for enabling agent-driven negotiation when the server is
  unwilling or unable to provide a varying response using server-driven
  negotiation.
  
  12.3 transparent negotiation
  
  transparent negotiation is a combination of both server-driven and
  agent-driven negotiation. when a cache is supplied with a form of the
  list of available representations of the response (as in agent-driven
  negotiation) and the dimensions of variance are completely understood
  by the cache, then the cache becomes capable of performing server-
  driven negotiation on behalf of the origin server for subsequent
  requests on that resource.
  
  transparent negotiation has the advantage of distributing the
  negotiation work that would otherwise be required of the origin
  server and also removing the second request delay of agent-driven
  negotiation when the cache is able to correctly guess the right
  response.
  
  this specification does not define any mechanism for transparent
  negotiation, though it also does not prevent any such mechanism from
  being developed as an extension that could be used within http/1.1.
  
  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,
  
  fielding, et al. standards track [page 74]
  
  rfc 2616 http/1.1 june 1999
  
  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.
  
  13.1.1 cache correctness
  
  a correct cache must respond to a request with the most up-to-date
  response held by the cache that is appropriate to the request (see
  sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
  conditions:
  
  1. it has been checked for equivalence with what the origin server
  would have returned by revalidating the response with the
  origin server (section 13.3);
  
  fielding, et al. standards track [page 75]
  
  rfc 2616 http/1.1 june 1999
  
  2. it is "fresh enough" (see section 13.2). in the default case,
  this means it meets the least restrictive freshness requirement
  of the client, origin server, and cache (see section 14.9); if
  the origin server so specifies, it is the freshness requirement
  of the origin server alone.
  
  if a stored response is not "fresh enough" by the most
  restrictive freshness requirement of both the client and the
  origin server, in carefully considered circumstances the cache
  may still return the response with the appropriate warning
  header (see section 13.1.5 and 14.46), unless such a response
  is prohibited (e.g., by a "no-store" cache-directive, or by a
  "no-cache" cache-request-directive; see section 14.9).
  
  3. it is an appropriate 304 (not modified), 305 (proxy redirect),
  or error (4xx or 5xx) response message.
  
  if the cache can not communicate with the origin server, then a
  correct cache should respond as above if the response can be
  correctly served from the cache; if not it must return an error or
  warning indicating that there was a communication failure.
  
  if a cache receives a response (either an entire response, or a 304
  (not modified) response) that it would normally forward to the
  requesting client, and the received response is no longer fresh, the
  cache should forward it to the requesting client without adding a new
  warning (but without removing any existing warning headers). a cache
  should not attempt to revalidate a response simply because that
  response became stale in transit; this might lead to an infinite
  loop. a user agent that receives a stale response without a warning
  may display a warning indication to the user.
  
  13.1.2 warnings
  
  whenever a cache returns a response that is neither first-hand nor
  "fresh enough" (in the sense of condition 2 in section 13.1.1), it
  must attach a warning to that effect, using a warning general-header.
  the warning header and the currently defined warnings are described
  in section 14.46. the warning allows clients to take appropriate
  action.
  
  warnings may be used for other purposes, both cache-related and
  otherwise. the use of a warning, rather than an error status code,
  distinguish these responses from true failures.
  
  warnings are assigned three digit warn-codes. the first digit
  indicates whether the warning must or must not be deleted from a
  stored cache entry after a successful revalidation:
  
  fielding, et al. standards track [page 76]
  
  rfc 2616 http/1.1 june 1999
  
  1xx warnings that describe the freshness or revalidation status of
  the response, and so must be deleted after a successful
  revalidation. 1xx warn-codes may be generated by a cache only when
  validating a cached entry. it must not be generated by clients.
  
  2xx warnings that describe some aspect of the entity body or entity
  headers that is not rectified by a revalidation (for example, a
  lossy compression of the entity bodies) and which must not be
  deleted after a successful revalidation.
  
  see section 14.46 for the definitions of the codes themselves.
  
  http/1.0 caches will cache all warnings in responses, without
  deleting the ones in the first category. warnings in responses that
  are passed to http/1.0 caches carry an extra warning-date field,
  which prevents a future http/1.1 recipient from believing an
  erroneously cached warning.
  
  warnings also carry a warning text. the text may be in any
  appropriate natural language (perhaps based on the client's accept
  headers), and include an optional indication of what character set is
  used.
  
  multiple warnings may be attached to a response (either by the origin
  server or by a cache), including multiple warnings with the same code
  number. for example, a server might provide the same warning with
  texts in both english and basque.
  
  when multiple warnings are attached to a response, it might not be
  practical or reasonable to display all of them to the user. this
  version of http does not specify strict priority rules for deciding
  which warnings to display and in what order, but does suggest some
  heuristics.
  
  13.1.3 cache-control mechanisms
  
  the basic cache mechanisms in http/1.1 (server-specified expiration
  times and validators) are implicit directives to caches. in some
  cases, a server or client might need to provide explicit directives
  to the http caches. we use the cache-control header for this purpose.
  
  the cache-control header allows a client or server to transmit a
  variety of directives in either requests or responses. these
  directives typically override the default caching algorithms. as a
  general rule, if there is any apparent conflict between header
  values, the most restrictive interpretation is applied (that is, the
  one that is most likely to preserve semantic transparency). however,
  
  fielding, et al. standards track [page 77]
  
  rfc 2616 http/1.1 june 1999
  
  in some cases, cache-control directives are explicitly specified as
  weakening the approximation of semantic transparency (for example,
  "max-stale" or "public").
  
  the cache-control directives are described in detail in section 14.9.
  
  13.1.4 explicit user agent warnings
  
  many user agents make it possible for users to override the basic
  caching mechanisms. for example, the user agent might allow the user
  to specify that cached entities (even explicitly stale ones) are
  never validated. or the user agent might habitually add "cache-
  control: max-stale=3600" to every request. the user agent should not
  default to either non-transparent behavior, or behavior that results
  in abnormally ineffective caching, but may be explicitly configured
  to do so by an explicit action of the user.
  
  if the user has overridden the basic caching mechanisms, the user
  agent should explicitly indicate to the user whenever this results in
  the display of information that might not meet the server's
  transparency requirements (in particular, if the displayed entity is
  known to be stale). since the protocol normally allows the user agent
  to determine if responses are stale or not, this indication need only
  be displayed when this actually happens. the indication need not be a
  dialog box; it could be an icon (for example, a picture of a rotting
  fish) or some other indicator.
  
  if the user has overridden the caching mechanisms in a way that would
  abnormally reduce the effectiveness of caches, the user agent should
  continually indicate this state to the user (for example, by a
  display of a picture of currency in flames) so that the user does not
  inadvertently consume excess resources or suffer from excessive
  latency.
  
  13.1.5 exceptions to the rules and warnings
  
  in some cases, the operator of a cache may choose to configure it to
  return stale responses even when not requested by clients. this
  decision ought not be made lightly, but may be necessary for reasons
  of availability or performance, especially when the cache is poorly
  connected to the origin server. whenever a cache returns a stale
  response, it must mark it as such (using a warning header) enabling
  the client software to alert the user that there might be a potential
  problem.
  
  fielding, et al. standards track [page 78]
  
  rfc 2616 http/1.1 june 1999
  
  it also allows the user agent to take steps to obtain a first-hand or
  fresh response. for this reason, a cache should not return a stale
  response if the client explicitly requests a first-hand or fresh one,
  unless it is impossible to comply for technical or policy reasons.
  
  13.1.6 client-controlled behavior
  
  while the origin server (and to a lesser extent, intermediate caches,
  by their contribution to the age of a response) are the primary
  source of expiration information, in some cases the client might need
  to control a cache's decision about whether to return a cached
  response without validating it. clients do this using several
  directives of the cache-control header.
  
  a client's request may specify the maximum age it is willing to
  accept of an unvalidated response; specifying a value of zero forces
  the cache(s) to revalidate all responses. a client may also specify
  the minimum time remaining before a response expires. both of these
  options increase constraints on the behavior of caches, and so cannot
  further relax the cache's approximation of semantic transparency.
  
  a client may also specify that it will accept stale responses, up to
  some maximum amount of staleness. this loosens the constraints on the
  caches, and so might violate the origin server's specified
  constraints on semantic transparency, but might be necessary to
  support disconnected operation, or high availability in the face of
  poor connectivity.
  
  13.2 expiration model
  
  13.2.1 server-specified expiration
  
  http caching works best when caches can entirely avoid making
  requests to the origin server. the primary mechanism for avoiding
  requests is for an origin server to provide an explicit expiration
  time in the future, indicating that a response may be used to satisfy
  subsequent requests. in other words, a cache can return a fresh
  response without first contacting the server.
  
  our expectation is that servers will assign future explicit
  expiration times to responses in the belief that the entity is not
  likely to change, in a semantically significant way, before the
  expiration time is reached. this normally preserves semantic
  transparency, as long as the server's expiration times are carefully
  chosen.
  
  fielding, et al. standards track [page 79]
  
  rfc 2616 http/1.1 june 1999
  
  the expiration mechanism applies only to responses taken from a cache
  and not to first-hand responses forwarded immediately to the
  requesting client.
  
  if an origin server wishes to force a semantically transparent cache
  to validate every request, it may assign an explicit expiration time
  in the past. this means that the response is always stale, and so the
  cache should validate it before using it for subsequent requests. see
  section 14.9.4 for a more restrictive way to force revalidation.
  
  if an origin server wishes to force any http/1.1 cache, no matter how
  it is configured, to validate every request, it should use the "must-
  revalidate" cache-control directive (see section 14.9).
  
  servers specify explicit expiration times using either the expires
  header, or the max-age directive of the cache-control header.
  
  an expiration time cannot be used to force a user agent to refresh
  its display or reload a resource; its semantics apply only to caching
  mechanisms, and such mechanisms need only check a resource's
  expiration status when a new request for that resource is initiated.
  see section 13.13 for an explanation of the difference between caches
  and history mechanisms.
  
  13.2.2 heuristic expiration
  
  since origin servers do not always provide explicit expiration times,
  http caches typically assign heuristic expiration times, employing
  algorithms that use other header values (such as the last-modified
  time) to estimate a plausible expiration time. the http/1.1
  specification does not provide specific algorithms, but does impose
  worst-case constraints on their results. since heuristic expiration
  times might compromise semantic transparency, they ought to used
  cautiously, and we encourage origin servers to provide explicit
  expiration times as much as possible.
  
  13.2.3 age calculations
  
  in order to know if a cached entry is fresh, a cache needs to know if
  its age exceeds its freshness lifetime. we discuss how to calculate
  the latter in section 13.2.4; this section describes how to calculate
  the age of a response or cache entry.
  
  in this discussion, we use the term "now" to mean "the current value
  of the clock at the host performing the calculation." hosts that use
  http, but especially hosts running origin servers and caches, should
  use ntp [28] or some similar protocol to synchronize their clocks to
  a globally accurate time standard.
  
  fielding, et al. standards track [page 80]
  
  rfc 2616 http/1.1 june 1999
  
  http/1.1 requires origin servers to send a date header, if possible,
  with every response, giving the time at which the response was
  generated (see section 14.18). we use the term "date_value" to denote
  the value of the date header, in a form appropriate for arithmetic
  operations.
  
  http/1.1 uses the age response-header to convey the estimated age of
  the response message when obtained from a cache. the age field value
  is the cache's estimate of the amount of time since the response was
  generated or revalidated by the origin server.
  
  in essence, the age value is the sum of the time that the response
  has been resident in each of the caches along the path from the
  origin server, plus the amount of time it has been in transit along
  network paths.
  
  we use the term "age_value" to denote the value of the age header, in
  a form appropriate for arithmetic operations.
  
  a response's age can be calculated in two entirely independent ways:
  
  1. now minus date_value, if the local clock is reasonably well
  synchronized to the origin server's clock. if the result is
  negative, the result is replaced by zero.
  
  2. age_value, if all of the caches along the response path
  implement http/1.1.
  
  given that we have two independent ways to compute the age of a
  response when it is received, we can combine these as
  
  corrected_received_age = max(now - date_value, age_value)
  
  and as long as we have either nearly synchronized clocks or all-
  http/1.1 paths, one gets a reliable (conservative) result.
  
  because of network-imposed delays, some significant interval might
  pass between the time that a server generates a response and the time
  it is received at the next outbound cache or client. if uncorrected,
  this delay could result in improperly low ages.
  
  because the request that resulted in the returned age value must have
  been initiated prior to that age value's generation, we can correct
  for delays imposed by the network by recording the time at which the
  request was initiated. then, when an age value is received, it must
  be interpreted relative to the time the request was initiated, not