13.3 Validation Model

   When a cache has a stale entry that it would like to use as a
   response to a client's request, it first has to check with the origin
   server (or possibly an intermediate cache with a fresh response) to
   see if its cached entry is still usable. We call this "validating"
   the cache entry.  Since we do not want to have to pay the overhead of
   retransmitting the full response if the cached entry is good, and we
   do not want to pay the overhead of an extra round trip if the cached
   entry is invalid, the HTTP/1.1 protocol supports the use of
   conditional methods.

   The key protocol features for supporting conditional methods are
   those concerned with "cache validators." When an origin server
   generates a full response, it attaches some sort of validator to it,
   which is kept with the cache entry. When a client (user agent or
   proxy cache) makes a conditional request for a resource for which it
   has a cache entry, it includes the associated validator in the
   request.

   The server then checks that validator against the current validator
   for the entity, and, if they match, it responds with a special status
   code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it
   returns a full response (including entity-body). Thus, we avoid
   transmitting the full response if the validator matches, and we avoid
   an extra round trip if it does not match.

     Note: the comparison functions used to decide if validators match
     are defined in section 13.3.3.

   In HTTP/1.1, a conditional request looks exactly the same as a normal
   request for the same resource, except that it carries a special
   header (which includes the validator) that implicitly turns the
   method (usually, GET) into a conditional.

   The protocol includes both positive and negative senses of cache-
   validating conditions. That is, it is possible to request either that
   a method be performed if and only if a validator matches or if and
   only if no validators match.

     Note: a response that lacks a validator may still be cached, and
     served from cache until it expires, unless this is explicitly
     prohibited by a Cache-Control directive. However, a cache cannot do
     a conditional retrieval if it does not have a validator for the
     entity, which means it will not be refreshable after it expires.

13.3.1 Last-modified Dates

   The Last-Modified entity-header field value is often used as a cache
   validator. In simple terms, a cache entry is considered to be valid
   if the entity has not been modified since the Last-Modified value.

13.3.2 Entity Tag Cache Validators

   The ETag entity-header field value, an entity tag, provides for an
   "opaque" cache validator. This may allow more reliable validation in
   situations where it is inconvenient to store modification dates,
   where the one-second resolution of HTTP date values is not
   sufficient, or where the origin server wishes to avoid certain
   paradoxes that may arise from the use of modification dates.

   Entity Tags are described in section 3.11. The headers used with
   entity tags are described in sections 14.20, 14.25, 14.26 and 14.43.

13.3.3 Weak and Strong Validators

   Since both origin servers and caches will compare two validators to
   decide if they represent the same or different entities, one normally
   would expect that if the entity (the entity-body or any entity-
   headers) changes in any way, then the associated validator would
   change as well.  If this is true, then we call this validator a
   "strong validator."

   However, there may be cases when a server prefers to change the
   validator only on semantically significant changes, and not when

   insignificant aspects of the entity change. A validator that does not
   always change when the resource changes is a "weak validator."

   Entity tags are normally "strong validators," but the protocol
   provides a mechanism to tag an entity tag as "weak." One can think of
   a strong validator as one that changes whenever the bits of an entity
   changes, while a weak value changes whenever the meaning of an entity
   changes.  Alternatively, one can think of a strong validator as part
   of an identifier for a specific entity, while a weak validator is
   part of an identifier for a set of semantically equivalent entities.

     Note: One example of a strong validator is an integer that is
     incremented in stable storage every time an entity is changed.

     An entity's modification time, if represented with one-second
     resolution, could be a weak validator, since it is possible that
     the resource may be modified twice during a single second.

     Support for weak validators is optional; however, weak validators
     allow for more efficient caching of equivalent objects; for
     example, a hit counter on a site is probably good enough if it is
     updated every few days or weeks, and any value during that period
     is likely "good enough" to be equivalent.

     A "use" of a validator is either when a client generates a request
     and includes the validator in a validating header field, or when a
     server compares two validators.

   Strong validators are usable in any context. Weak validators are only
   usable in contexts that do not depend on exact equality of an entity.
   For example, either kind is usable for a conditional GET of a full
   entity. However, only a strong validator is usable for a sub-range
   retrieval, since otherwise the client may end up with an internally
   inconsistent entity.

   The only function that the HTTP/1.1 protocol defines on validators is
   comparison. There are two validator comparison functions, depending
   on whether the comparison context allows the use of weak validators
   or not:

  o  The strong comparison function: in order to be considered equal,
     both validators must be identical in every way, and neither may be
     weak.
  o  The weak comparison function: in order to be considered equal, both
     validators must be identical in every way, but either or both of
     them may be tagged as "weak" without affecting the result.

   The weak comparison function MAY be used for simple (non-subrange)

   GET requests. The strong comparison function MUST be used in all
   other cases.

   An entity tag is strong unless it is explicitly tagged as weak.
   Section 3.11 gives the syntax for entity tags.

   A Last-Modified time, when used as a validator in a request, is
   implicitly weak unless it is possible to deduce that it is strong,
   using the following rules:

  o  The validator is being compared by an origin server to the actual
     current validator for the entity and,
  o  That origin server reliably knows that the associated entity did
     not change twice during the second covered by the presented
     validator.
or

  o  The validator is about to be used by a client in an If-Modified-
     Since or If-Unmodified-Since header, because the client has a cache
     entry for the associated entity, and
  o  That cache entry includes a Date value, which gives the time when
     the origin server sent the original response, and
  o  The presented Last-Modified time is at least 60 seconds before the
     Date value.
or

  o  The validator is being compared by an intermediate cache to the
     validator stored in its cache entry for the entity, and
  o  That cache entry includes a Date value, which gives the time when
     the origin server sent the original response, and
  o  The presented Last-Modified time is at least 60 seconds before the
     Date value.

   This method relies on the fact that if two different responses were
   sent by the origin server during the same second, but both had the
   same Last-Modified time, then at least one of those responses would
   have a Date value equal to its Last-Modified time. The arbitrary 60-
   second limit guards against the possibility that the Date and Last-
   Modified values are generated from different clocks, or at somewhat
   different times during the preparation of the response. An
   implementation may use a value larger than 60 seconds, if it is
   believed that 60 seconds is too short.

   If a client wishes to perform a sub-range retrieval on a value for
   which it has only a Last-Modified time and no opaque validator, it
   may do this only if the Last-Modified time is strong in the sense
   described here.

   A cache or origin server receiving a cache-conditional request, other
   than a full-body GET request, MUST use the strong comparison function
   to evaluate the condition.

   These rules allow HTTP/1.1 caches and clients to safely perform sub-
   range retrievals on values that have been obtained from HTTP/1.0
   servers.

13.3.4 Rules for When to Use Entity Tags and Last-modified Dates

   We adopt a set of rules and recommendations for origin servers,
   clients, and caches regarding when various validator types should be
   used, and for what purposes.

   HTTP/1.1 origin servers:

  o  SHOULD send an entity tag validator unless it is not feasible to
     generate one.
  o  MAY send a weak entity tag instead of a strong entity tag, if
     performance considerations support the use of weak entity tags, or
     if it is unfeasible to send a strong entity tag.
  o  SHOULD send a Last-Modified value if it is feasible to send one,
     unless the risk of a breakdown in semantic transparency that could
     result from using this date in an If-Modified-Since header would
     lead to serious problems.

   In other words, the preferred behavior for an HTTP/1.1 origin server
   is to send both a strong entity tag and a Last-Modified value.

   In order to be legal, a strong entity tag MUST change whenever the
   associated entity value changes in any way. A weak entity tag SHOULD
   change whenever the associated entity changes in a semantically
   significant way.

     Note: in order to provide semantically transparent caching, an
     origin server must avoid reusing a specific strong entity tag value
     for two different entities, or reusing a specific weak entity tag
     value for two semantically different entities. Cache entries may
     persist for arbitrarily long periods, regardless of expiration
     times, so it may be inappropriate to expect that a cache will never
     again attempt to validate an entry using a validator that it
     obtained at some point in the past.

   HTTP/1.1 clients:

     o  If an entity tag has been provided by the origin server, MUST
        use that entity tag in any cache-conditional request (using
        If-Match or If-None-Match).

     o  If only a Last-Modified value has been provided by the origin
        server, SHOULD use that value in non-subrange cache-conditional
        requests (using If-Modified-Since).
     o  If only a Last-Modified value has been provided by an HTTP/1.0
        origin server, MAY use that value in subrange cache-conditional
        requests (using If-Unmodified-Since:). The user agent should
        provide a way to disable this, in case of difficulty.
     o  If both an entity tag and a Last-Modified value have been
        provided by the origin server, SHOULD use both validators in
        cache-conditional requests. This allows both HTTP/1.0 and
        HTTP/1.1 caches to respond appropriately.

   An HTTP/1.1 cache, upon receiving a request, MUST use the most
   restrictive validator when deciding whether the client's cache entry
   matches the cache's own cache entry. This is only an issue when the
   request contains both an entity tag and a last-modified-date
   validator (If-Modified-Since or If-Unmodified-Since).

     A note on rationale: The general principle behind these rules is
     that HTTP/1.1 servers and clients should transmit as much non-
     redundant information as is available in their responses and
     requests. HTTP/1.1 systems receiving this information will make the
     most conservative assumptions about the validators they receive.

     HTTP/1.0 clients and caches will ignore entity tags. Generally,
     last-modified values received or used by these systems will support
     transparent and efficient caching, and so HTTP/1.1 origin servers
     should provide Last-Modified values. In those rare cases where the
     use of a Last-Modified value as a validator by an HTTP/1.0 system
     could result in a serious problem, then HTTP/1.1 origin servers
     should not provide one.

13.3.5 Non-validating Conditionals

   The principle behind entity tags is that only the service author
   knows the semantics of a resource well enough to select an
   appropriate cache validation mechanism, and the specification of any
   validator comparison function more complex than byte-equality would
   open up a can of worms.  Thus, comparisons of any other headers
   (except Last-Modified, for compatibility with HTTP/1.0) are never
   used for purposes of validating a cache entry.

13.4 Response Cachability

   Unless specifically constrained by a Cache-Control (section 14.9)
   directive, a caching system may always store a successful response
   (see section 13.8) as a cache entry, may return it without validation
   if it is fresh, and may return it after successful validation. If

   there is neither a cache validator nor an explicit expiration time
   associated with a response, we do not expect it to be cached, but
   certain caches may violate this expectation (for example, when little
   or no network connectivity is available). A client can usually detect
   that such a response was taken from a cache by comparing the Date
   header to the current time.

     Note that some HTTP/1.0 caches are known to violate this
     expectation without providing any Warning.

   However, in some cases it may be inappropriate for a cache to retain
   an entity, or to return it in response to a subsequent request. This
   may be because absolute semantic transparency is deemed necessary by
   the service author, or because of security or privacy considerations.
   Certain Cache-Control directives are therefore provided so that the
   server can indicate that certain resource entities, or portions
   thereof, may not be cached regardless of other considerations.

   Note that section 14.8 normally prevents a shared cache from saving
   and returning a response to a previous request if that request
   included an Authorization header.

   A response received with a status code of 200, 203, 206, 300, 301 or
   410 may be stored by a cache and used in reply to a subsequent
   request, subject to the expiration mechanism, unless a Cache-Control
   directive prohibits caching. However, a cache that does not support
   the Range and Content-Range headers MUST NOT cache 206 (Partial
   Content) responses.

   A response received with any other status code MUST NOT be returned
   in a reply to a subsequent request unless there are Cache-Control
   directives or another header(s) that explicitly allow it. For
   example, these include the following: an Expires header (section
   14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
   or "private" Cache-Control directive (section 14.9).

13.5 Constructing Responses From Caches

   The purpose of an HTTP cache is to store information received in
   response to requests, for use in responding to future requests. In
   many cases, a cache simply returns the appropriate parts of a
   response to the requester. However, if the cache holds a cache entry
   based on a previous response, it may have to combine parts of a new
   response with what is held in the cache entry.

13.5.1 End-to-end and Hop-by-hop Headers

   For the purpose of defining the behavior of caches and non-caching
   proxies, we divide HTTP headers into two categories:

  o  End-to-end headers, which must be transmitted to the
     ultimate recipient of a request or response. End-to-end
     headers in responses must be stored as part of a cache entry
     and transmitted in any response formed from a cache entry.
  o  Hop-by-hop headers, which are meaningful only for a single
     transport-level connection, and are not stored by caches or
     forwarded by proxies.

   The following HTTP/1.1 headers are hop-by-hop headers:

     o  Connection
     o  Keep-Alive
     o  Public
     o  Proxy-Authenticate
     o  Transfer-Encoding
     o  Upgrade

   All other headers defined by HTTP/1.1 are end-to-end headers.

   Hop-by-hop headers introduced in future versions of HTTP MUST be
   listed in a Connection header, as described in section 14.10.

13.5.2 Non-modifiable Headers

   Some features of the HTTP/1.1 protocol, such as Digest
   Authentication, depend on the value of certain end-to-end headers. A
   cache or non-caching proxy SHOULD NOT modify an end-to-end header
   unless the definition of that header requires or specifically allows
   that.

   A cache or non-caching proxy MUST NOT modify any of the following
   fields in a request or response, nor may it add any of these fields
   if not already present:

     o  Content-Location
     o  ETag
     o  Expires
     o  Last-Modified

   A cache or non-caching proxy MUST NOT modify or add any of the
   following fields in a response that contains the no-transform Cache-
   Control directive, or in any request:

     o  Content-Encoding
     o  Content-Length
     o  Content-Range
     o  Content-Type

   A cache or non-caching proxy MAY modify or add these fields in a
   response that does not include no-transform, but if it does so, it
   MUST add a Warning 14 (Transformation applied) if one does not
   already appear in the response.

     Warning: unnecessary modification of end-to-end headers may cause
     authentication failures if stronger authentication mechanisms are
     introduced in later versions of HTTP. Such authentication
     mechanisms may rely on the values of header fields not listed here.

13.5.3 Combining Headers

   When a cache makes a validating request to a server, and the server
   provides a 304 (Not Modified) response, the cache must construct a
   response to send to the requesting client. The cache uses the
   entity-body stored in the cache entry as the entity-body of this
   outgoing response. The end-to-end headers stored in the cache entry
   are used for the constructed response, except that any end-to-end
   headers provided in the 304 response MUST replace the corresponding
   headers from the cache entry. Unless the cache decides to remove the
   cache entry, it MUST also replace the end-to-end headers stored with
   the cache entry with corresponding headers received in the incoming
   response.

   In other words, the set of end-to-end headers received in the
   incoming response overrides all corresponding end-to-end headers
   stored with the cache entry. The cache may add Warning headers (see
   section 14.45) to this set.

   If a header field-name in the incoming response matches more than one
   header in the cache entry, all such old headers are replaced.

     Note: this rule allows an origin server to use a 304 (Not Modified)
     response to update any header associated with a previous response
     for the same entity, although it might not always be meaningful or
     correct to do so. This rule does not allow an origin server to use
     a 304 (not Modified) response to entirely delete a header that it
     had provided with a previous response.

13.5.4 Combining Byte Ranges

   A response may transfer only a subrange of the bytes of an entity-
   body, either because the request included one or more Range
   specifications, or because a connection was broken prematurely. After
   several such transfers, a cache may have received several ranges of
   the same entity-body.

   If a cache has a stored non-empty set of subranges for an entity, and
   an incoming response transfers another subrange, the cache MAY
   combine the new subrange with the existing set if both the following
   conditions are met:

     o  Both the incoming response and the cache entry must have a cache
        validator.
     o  The two cache validators must match using the strong comparison
        function (see section 13.3.3).

   If either requirement is not meant, the cache must use only the most
   recent partial response (based on the Date values transmitted with
   every response, and using the incoming response if these values are
   equal or missing), and must discard the other partial information.

13.6 Caching Negotiated Responses

   Use of server-driven content negotiation (section 12), as indicated
   by the presence of a Vary header field in a response, alters the
   conditions and procedure by which a cache can use the response for
   subsequent requests.

   A server MUST use the Vary header field (section 14.43) to inform a
   cache of what header field dimensions are used to select among
   multiple representations of a cachable response. A cache may use the
   selected representation (the entity included with that particular
   response) for replying to subsequent requests on that resource only
   when the subsequent requests have the same or equivalent values for
   all header fields specified in the Vary response-header. Requests
   with a different value for one or more of those header fields would
   be forwarded toward the origin server.

   If an entity tag was assigned to the representation, the forwarded
   request SHOULD be conditional and include the entity tags in an If-
   None-Match header field from all its cache entries for the Request-
   URI. This conveys to the server the set of entities currently held by
   the cache, so that if any one of these entities matches the requested
   entity, the server can use the ETag header in its 304 (Not Modified)
   response to tell the cache which entry is appropriate. If the
   entity-tag of the new response matches that of an existing entry, the

   new response SHOULD be used to update the header fields of the
   existing entry, and the result MUST be returned to the client.

   The Vary header field may also inform the cache that the
   representation was selected using criteria not limited to the
   request-headers; in this case, a cache MUST NOT use the response in a
   reply to a subsequent request unless the cache relays the new request
   to the origin server in a conditional request and the server responds
   with 304 (Not Modified), including an entity tag or Content-Location
   that indicates which entity should be used.

   If any of the existing cache entries contains only partial content
   for the associated entity, its entity-tag SHOULD NOT be included in
   the If-None-Match header unless the request is for a range that would
   be fully satisfied by that entry.

   If a cache receives a successful response whose Content-Location
   field matches that of an existing cache entry for the same Request-
   URI, whose entity-tag differs from that of the existing entry, and
   whose Date is more recent than that of the existing entry, the
   existing entry SHOULD NOT be returned in response to future requests,
   and should be deleted from the cache.

13.7 Shared and Non-Shared Caches

   For reasons of security and privacy, it is necessary to make a
   distinction between "shared" and "non-shared" caches. A non-shared
   cache is one that is accessible only to a single user. Accessibility
   in this case SHOULD be enforced by appropriate security mechanisms.
   All other caches are considered to be "shared." Other sections of
   this specification place certain constraints on the operation of
   shared caches in order to prevent loss of privacy or failure of
   access controls.

13.8 Errors or Incomplete Response Cache Behavior

   A cache that receives an incomplete response (for example, with fewer
   bytes of data than specified in a Content-Length header) may store
   the response. However, the cache MUST treat this as a partial
   response.  Partial responses may be combined as described in section
   13.5.4; the result might be a full response or might still be
   partial. A cache MUST NOT return a partial response to a client
   without explicitly marking it as such, using the 206 (Partial
   Content) status code. A cache MUST NOT return a partial response
   using a status code of 200 (OK).

   If a cache receives a 5xx response while attempting to revalidate an
   entry, it may either forward this response to the requesting client,

   or act as if the server failed to respond. In the latter case, it MAY
   return a previously received response unless the cached entry
   includes the "must-revalidate" Cache-Control directive (see section
   14.9).

13.9 Side Effects of GET and HEAD

   Unless the origin server explicitly prohibits the caching of their
   responses, the application of GET and HEAD methods to any resources
   SHOULD NOT have side effects that would lead to erroneous behavior if
   these responses are taken from a cache. They may still have side
   effects, but a cache is not required to consider such side effects in
   its caching decisions. Caches are always expected to observe an
   origin server's explicit restrictions on caching.

   We note one exception to this rule: since some applications have
   traditionally used GETs and HEADs with query URLs (those containing a
   "?" in the rel_path part) to perform operations with significant side
   effects, caches MUST NOT treat responses to such URLs as fresh unless
   the server provides an explicit expiration time. This specifically
   means that responses from HTTP/1.0 servers for such URIs should not
   be taken from a cache. See section 9.1.1 for related information.

13.10 Invalidation After Updates or Deletions

   The effect of certain methods at the origin server may cause one or
   more existing cache entries to become non-transparently invalid. That
   is, although they may continue to be "fresh," they do not accurately
   reflect what the origin server would return for a new request.

   There is no way for the HTTP protocol to guarantee that all such
   cache entries are marked invalid. For example, the request that
   caused the change at the origin server may not have gone through the
   proxy where a cache entry is stored. However, several rules help
   reduce the likelihood of erroneous behavior.

   In this section, the phrase "invalidate an entity" means that the
   cache should either remove all instances of that entity from its
   storage, or should mark these as "invalid" and in need of a mandatory
   revalidation before they can be returned in response to a subsequent
   request.

   Some HTTP methods may invalidate an entity. This is either the entity
   referred to by the Request-URI, or by the Location or Content-
   Location response-headers (if present). These methods are:

     o  PUT
     o  DELETE
     o  POST

   In order to prevent denial of service attacks, an invalidation based
   on the URI in a Location or Content-Location header MUST only be
   performed if the host part is the same as in the Request-URI.

13.11 Write-Through Mandatory

   All methods that may be expected to cause modifications to the origin
   server's resources MUST be written through to the origin server. This
   currently includes all methods except for GET and HEAD. A cache MUST
   NOT reply to such a request from a client before having transmitted
   the request to the inbound server, and having received a
   corresponding response from the inbound server. This does not prevent
   a cache from sending a 100 (Continue) response before the inbound
   server has replied.

   The alternative (known as "write-back" or "copy-back" caching) is not
   allowed in HTTP/1.1, due to the difficulty of providing consistent
   updates and the problems arising from server, cache, or network
   failure prior to write-back.

13.12 Cache Replacement

   If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
   response is received from a resource while any existing responses for
   the same resource are cached, the cache SHOULD use the new response
   to reply to the current request. It may insert it into cache storage
   and may, if it meets all other requirements, use it to respond to any
   future requests that would previously have caused the old response to
   be returned. If it inserts the new response into cache storage it
   should follow the rules in section 13.5.3.

     Note: a new response that has an older Date header value than
     existing cached responses is not cachable.

13.13 History Lists

   User agents often have history mechanisms, such as "Back" buttons and
   history lists, which can be used to redisplay an entity retrieved
   earlier in a session.

   History mechanisms and caches are different. In particular history
   mechanisms SHOULD NOT try to show a semantically transparent view of
   the current state of a resource. Rather, a history mechanism is meant
   to show exactly what the user saw at the time when the resource was
   retrieved.

   By default, an expiration time does not apply to history mechanisms.
   If the entity is still in storage, a history mechanism should display
   it even if the entity has expired, unless the user has specifically
   configured the agent to refresh expired history documents.

   This should not be construed to prohibit the history mechanism from
   telling the user that a view may be stale.

     Note: if history list mechanisms unnecessarily prevent users from
     viewing stale resources, this will tend to force service authors to
     avoid using HTTP expiration controls and cache controls when they
     would otherwise like to. Service authors may consider it important
     that users not be presented with error messages or warning messages
     when they use navigation controls (such as BACK) to view previously
     fetched resources. Even though sometimes such resources ought not
     to cached, or ought to expire quickly, user interface
     considerations may force service authors to resort to other means
     of preventing caching (e.g. "once-only" URLs) in order not to
     suffer the effects of improperly functioning history mechanisms.

14 Header Field Definitions

   This section defines the syntax and semantics of all standard
   HTTP/1.1 header fields. For entity-header fields, both sender and
   recipient refer to either the client or the server, depending on who
   sends and who receives the entity.

14.1 Accept

   The Accept request-header field can be used to specify certain media
   types which are acceptable for the response. Accept headers can be
   used to indicate that the request is specifically limited to a small
   set of desired types, as in the case of a request for an in-line
   image.

          Accept         = "Accept" ":"
                           #( media-range [ accept-params ] )

          media-range    = ( "*/*"
                           | ( type "/" "*" )
                           | ( type "/" subtype )
                           ) *( ";" parameter )

          accept-params  = ";" "q" "=" qvalue *( accept-extension )

          accept-extension = ";" token [ "=" ( token | quoted-string ) ]

   The asterisk "*" character is used to group media types into ranges,
   with "*/*" indicating all media types and "type/*" indicating all
   subtypes of that type. The media-range MAY include media type
   parameters that are applicable to that range.

   Each media-range MAY be followed by one or more accept-params,
   beginning with the "q" parameter for indicating a relative quality
   factor. The first "q" parameter (if any) separates the media-range
   parameter(s) from the accept-params. Quality factors allow the user
   or user agent to indicate the relative degree of preference for that
   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
   default value is q=1.

     Note: Use of the "q" parameter name to separate media type
     parameters from Accept extension parameters is due to historical
     practice.  Although this prevents any media type parameter named
     "q" from being used with a media range, such an event is believed
     to be unlikely given the lack of any "q" parameters in the IANA
     media type registry and the rare usage of any media type parameters
     in Accept. Future media types should be discouraged from
     registering any parameter named "q".

   The example

          Accept: audio/*; q=0.2, audio/basic

   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
   type if it is the best available after an 80% mark-down in quality."

   If no Accept header field is present, then it is assumed that the
   client accepts all media types. If an Accept header field is present,
   and if the server cannot send a response which is acceptable
   according to the combined Accept field value, then the server SHOULD
   send a 406 (not acceptable) response.

   A more elaborate example is

          Accept: text/plain; q=0.5, text/html,
                  text/x-dvi; q=0.8, text/x-c

   Verbally, this would be interpreted as "text/html and text/x-c are
   the preferred media types, but if they do not exist, then send the
   text/x-dvi entity, and if that does not exist, send the text/plain
   entity."

   Media ranges can be overridden by more specific media ranges or
   specific media types. If more than one media range applies to a given
   type, the most specific reference has precedence. For example,

          Accept: text/*, text/html, text/html;level=1, */*

   have the following precedence:

          1) text/html;level=1
          2) text/html
          3) text/*
          4) */*

   The media type quality factor associated with a given type is
   determined by finding the media range with the highest precedence
   which matches that type. For example,

          Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
                  text/html;level=2;q=0.4, */*;q=0.5

   would cause the following values to be associated:

          text/html;level=1         = 1
          text/html                 = 0.7
          text/plain                = 0.3
          image/jpeg                = 0.5
          text/html;level=2         = 0.4
          text/html;level=3         = 0.7

     Note: A user agent may be provided with a default set of quality
     values for certain media ranges. However, unless the user agent is
     a closed system which cannot interact with other rendering agents,

     this default set should be configurable by the user.

14.2 Accept-Charset

   The Accept-Charset request-header field can be used to indicate what
   character sets are acceptable for the response. This field allows
   clients capable of understanding more comprehensive or special-
   purpose character sets to signal that capability to a server which is
   capable of representing documents in those character sets. The ISO-
   8859-1 character set can be assumed to be acceptable to all user
   agents.

          Accept-Charset = "Accept-Charset" ":"
                    1#( charset [ ";" "q" "=" qvalue ] )

   Character set values are described in section 3.4. Each charset may
   be given an associated quality value which represents the user's
   preference for that charset. The default value is q=1. An example is

          Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

   If no Accept-Charset header is present, the default is that any
   character set is acceptable. If an Accept-Charset header is present,
   and if the server cannot send a response which is acceptable
   according to the Accept-Charset header, then the server SHOULD send
   an error response with the 406 (not acceptable) status code, though
   the sending of an unacceptable response is also allowed.

14.3 Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-coding values (section 14.12) which are
   acceptable in the response.

          Accept-Encoding  = "Accept-Encoding" ":"
                                    #( content-coding )

   An example of its use is

          Accept-Encoding: compress, gzip

   If no Accept-Encoding header is present in a request, the server MAY
   assume that the client will accept any content coding. If an Accept-
   Encoding header is present, and if the server cannot send a response
   which is acceptable according to the Accept-Encoding header, then the
   server SHOULD send an error response with the 406 (Not Acceptable)
   status code.

   An empty Accept-Encoding value indicates none are acceptable.

14.4 Accept-Language

   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request.

          Accept-Language = "Accept-Language" ":"
                            1#( language-range [ ";" "q" "=" qvalue ] )

          language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

   Each language-range MAY be given an associated quality value which
   represents an estimate of the user's preference for the languages
   specified by that range. The quality value defaults to "q=1". For
   example,

          Accept-Language: da, en-gb;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English." A language-range matches a language-tag if
   it exactly equals the tag, or if it exactly equals a prefix of the
   tag such that the first tag character following the prefix is "-".
   The special range "*", if present in the Accept-Language field,
   matches every tag not matched by any other range present in the
   Accept-Language field.

     Note: This use of a prefix matching rule does not imply that
     language tags are assigned to languages in such a way that it is
     always true that if a user understands a language with a certain
     tag, then this user will also understand all languages with tags
     for which this tag is a prefix. The prefix rule simply allows the
     use of prefix tags if this is the case.

   The language quality factor assigned to a language-tag by the
   Accept-Language field is the quality value of the longest language-
   range in the field that matches the language-tag. If no language-
   range in the field matches the tag, the language quality factor
   assigned is 0. If no Accept-Language header is present in the
   request, the server SHOULD assume that all languages are equally
   acceptable. If an Accept-Language header is present, then all
   languages which are assigned a quality factor greater than 0 are
   acceptable.

   It may be contrary to the privacy expectations of the user to send an
   Accept-Language header with the complete linguistic preferences of
   the user in every request. For a discussion of this issue, see

   section 15.7.

     Note: As intelligibility is highly dependent on the individual
     user, it is recommended that client applications make the choice of
     linguistic preference available to the user. If the choice is not
     made available, then the Accept-Language header field must not be
     given in the request.

14.5 Accept-Ranges

   The Accept-Ranges response-header field allows the server to indicate
   its acceptance of range requests for a resource:

          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges

          acceptable-ranges = 1#range-unit | "none"

   Origin servers that accept byte-range requests MAY send

          Accept-Ranges: bytes

   but are not required to do so. Clients MAY generate byte-range
   requests without having received this header for the resource
   involved.

   Servers that do not accept any kind of range request for a  resource
   MAY send

          Accept-Ranges: none

   to advise the client not to attempt a range request.

14.6 Age

   The Age response-header field conveys the sender's estimate of the
   amount of time since the response (or its revalidation) was generated
   at the origin server. A cached response is "fresh" if its age does
   not exceed its freshness lifetime. Age values are calculated as
   specified in section 13.2.3.

           Age = "Age" ":" age-value

           age-value = delta-seconds

   Age values are non-negative decimal integers, representing time in
   seconds.

   If a cache receives a value larger than the largest positive integer
   it can represent, or if any of its age calculations overflows, it
   MUST transmit an Age header with a value of 2147483648 (2^31).
   HTTP/1.1 caches MUST send an Age header in every response. Caches
   SHOULD use an arithmetic type of at least 31 bits of range.

14.7 Allow

   The Allow entity-header field lists the set of methods supported by
   the resource identified by the Request-URI. The purpose of this field
   is strictly to inform the recipient of valid methods associated with
   the resource. An Allow header field MUST be present in a 405 (Method
   Not Allowed) response.

          Allow          = "Allow" ":" 1#method

   Example of use:

          Allow: GET, HEAD, PUT

   This field cannot prevent a client from trying other methods.
   However, the indications given by the Allow header field value SHOULD
   be followed. The actual set of allowed methods is defined by the
   origin server at the time of each request.

   The Allow header field MAY be provided with a PUT request to
   recommend the methods to be supported by the new or modified
   resource. The server is not required to support these methods and
   SHOULD include an Allow header in the response giving the actual
   supported methods.

   A proxy MUST NOT modify the Allow header field even if it does not
   understand all the methods specified, since the user agent MAY have
   other means of communicating with the origin server.

   The Allow header field does not indicate what methods are implemented
   at the server level. Servers MAY use the Public response-header field
   (section 14.35) to describe what methods are implemented on the
   server as a whole.

14.8 Authorization

   A user agent that wishes to authenticate itself with a server--
   usually, but not necessarily, after receiving a 401 response--MAY do
   so by including an Authorization request-header field with the
   request. The Authorization field value consists of credentials
   containing the authentication information of the user agent for the
   realm of the resource being requested.

          Authorization  = "Authorization" ":" credentials

   HTTP access authentication is described in section 11. If a request
   is authenticated and a realm specified, the same credentials SHOULD
   be valid for all other requests within this realm.

   When a shared cache (see section 13.7) receives a request containing
   an Authorization field, it MUST NOT return the corresponding response
   as a reply to any other request, unless one of the following specific
   exceptions holds:

     1. If the response includes the "proxy-revalidate" Cache-Control
        directive, the cache MAY use that response in replying to a
        subsequent request, but a proxy cache MUST first revalidate it with
        the origin server, using the request-headers from the new request
        to allow the origin server to authenticate the new request.
     2. If the response includes the "must-revalidate" Cache-Control
        directive, the cache MAY use that response in replying to a
        subsequent request, but all caches MUST first revalidate it with
        the origin server, using the request-headers from the new request
        to allow the origin server to authenticate the new request.
     3. If the response includes the "public" Cache-Control directive, it
        may be returned in reply to any subsequent request.

14.9 Cache-Control

   The Cache-Control general-header field is used to specify directives
   that MUST be obeyed by all caching mechanisms along the
   request/response chain. The directives specify behavior intended to
   prevent caches from adversely interfering with the request or
   response. These directives typically override the default caching
   algorithms. Cache directives are unidirectional in that the presence
   of a directive in a request does not imply that the same directive
   should be given in the response.

     Note that HTTP/1.0 caches may not implement Cache-Control and may
     only implement Pragma: no-cache (see section 14.32).

   Cache directives must be passed through by a proxy or gateway
   application, regardless of their significance to that application,
   since the directives may be applicable to all recipients along the
   request/response chain. It is not possible to specify a cache-
   directive for a specific cache.

          Cache-Control   = "Cache-Control" ":" 1#cache-directive

          cache-directive = cache-request-directive
                          | cache-response-directive

          cache-request-directive =
                            "no-cache" [ "=" <"> 1#field-name <"> ]
                          | "no-store"
                          | "max-age" "=" delta-seconds
                          | "max-stale" [ "=" delta-seconds ]
                          | "min-fresh" "=" delta-seconds
                          | "only-if-cached"
                          | cache-extension

          cache-response-directive =
                            "public"
                          | "private" [ "=" <"> 1#field-name <"> ]
                          | "no-cache" [ "=" <"> 1#field-name <"> ]
                          | "no-store"
                          | "no-transform"
                          | "must-revalidate"
                          | "proxy-revalidate"
                          | "max-age" "=" delta-seconds
                          | cache-extension

          cache-extension = token [ "=" ( token | quoted-string ) ]

   When a directive appears without any 1#field-name parameter, the
   directive applies to the entire request or response. When such a
   directive appears with a 1#field-name parameter, it applies only to
   the named field or fields, and not to the rest of the request or
   response.  This mechanism supports extensibility; implementations of
   future versions of the HTTP protocol may apply these directives to
   header fields not defined in HTTP/1.1.

   The cache-control directives can be broken down into these general
   categories:

     o  Restrictions on what is cachable; these may only be imposed by the
        origin server.
     o  Restrictions on what may be stored by a cache; these may be imposed
        by either the origin server or the user agent.
     o  Modifications of the basic expiration mechanism; these may be
        imposed by either the origin server or the user agent.
     o  Controls over cache revalidation and reload; these may only be
        imposed by a user agent.
     o  Control over transformation of entities.
     o  Extensions to the caching system.

14.9.1 What is Cachable

   By default, a response is cachable if the requirements of the request
   method, request header fields, and the response status indicate that
   it is cachable. Section 13.4 summarizes these defaults for
   cachability. The following Cache-Control response directives allow an
   origin server to override the default cachability of a response:

public
  Indicates that the response is cachable by any cache, even if it
  would normally be non-cachable or cachable only within a non-shared
  cache. (See also Authorization, section 14.8, for additional
  details.)

private
  Indicates that all or part of the response message is intended for a
  single user and MUST NOT be cached by a shared cache. This allows an
  origin server to state that the specified parts of the response are
  intended for only one user and are not a valid response for requests
  by other users. A private (non-shared) cache may cache the response.

  Note: This usage of the word private only controls where the
  response may be cached, and cannot ensure the privacy of the
  message content.

no-cache
  Indicates that all or part of the response message MUST NOT be cached
  anywhere. This allows an origin server to prevent caching even by
  caches that have been configured to return stale responses to client
  requests.

  Note: Most HTTP/1.0 caches will not recognize or obey this
  directive.

14.9.2 What May be Stored by Caches

   The purpose of the no-store directive is to prevent the inadvertent
   release or retention of sensitive information (for example, on backup
   tapes). The no-store directive applies to the entire message, and may
   be sent either in a response or in a request. If sent in a request, a
   cache MUST NOT store any part of either this request or any response
   to it. If sent in a response, a cache MUST NOT store any part of
   either this response or the request that elicited it. This directive
   applies to both non-shared and shared caches. "MUST NOT store" in
   this context means that the cache MUST NOT intentionally store the
   information in non-volatile storage, and MUST make a best-effort
   attempt to remove the information from volatile storage as promptly
   as possible after forwarding it.

   Even when this directive is associated with a response, users may
   explicitly store such a response outside of the caching system (e.g.,
   with a "Save As" dialog). History buffers may store such responses as
   part of their normal operation.

   The purpose of this directive is to meet the stated requirements of
   certain users and service authors who are concerned about accidental
   releases of information via unanticipated accesses to cache data
   structures. While the use of this directive may improve privacy in
   some cases, we caution that it is NOT in any way a reliable or
   sufficient mechanism for ensuring privacy. In particular, malicious
   or compromised caches may not recognize or obey this directive; and
   communications networks may be vulnerable to eavesdropping.

14.9.3 Modifications of the Basic Expiration Mechanism

   The expiration time of an entity may be specified by the origin
   server using the Expires header (see section 14.21). Alternatively,
   it may be specified using the max-age directive in a response.

   If a response includes both an Expires header and a max-age
   directive, the max-age directive overrides the Expires header, even
   if the Expires header is more restrictive. This rule allows an origin
   server to provide, for a given response, a longer expiration time to
   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
   useful if certain HTTP/1.0 caches improperly calculate ages or
   expiration times, perhaps due to desynchronized clocks.

     Note: most older caches, not compliant with this specification, do
     not implement any Cache-Control directives.  An origin server
     wishing to use a Cache-Control directive that restricts, but does
     not prevent, caching by an HTTP/1.1-compliant cache may exploit the
     requirement that the max-age directive overrides the Expires
     header, and the fact that non-HTTP/1.1-compliant caches do not
     observe the max-age directive.

   Other directives allow an user agent to modify the basic expiration
   mechanism. These directives may be specified on a request:

   max-age
     Indicates that the client is willing to accept a response whose age
     is no greater than the specified time in seconds. Unless max-stale
     directive is also included, the client is not willing to accept a
     stale response.

   min-fresh
     Indicates that the client is willing to accept a response whose
     freshness lifetime is no less than its current age plus the

     specified time in seconds. That is, the client wants a response
     that will still be fresh for at least the specified number of
     seconds.

   max-stale
     Indicates that the client is willing to accept a response that has
     exceeded its expiration time. If max-stale is assigned a value,
     then the client is willing to accept a response that has exceeded
     its expiration time by no more than the specified number of
     seconds. If no value is assigned to max-stale, then the client is
     willing to accept a stale response of any age.

   If a cache returns a stale response, either because of a max-stale
   directive on a request, or because the cache is configured to
   override the expiration time of a response, the cache MUST attach a
   Warning header to the stale response, using Warning 10 (Response is
   stale).

14.9.4 Cache Revalidation and Reload Controls

   Sometimes an user agent may want or need to insist that a cache
   revalidate its cache entry with the origin server (and not just with
   the next cache along the path to the origin server), or to reload its
   cache entry from the origin server. End-to-end revalidation may be
   necessary if either the cache or the origin server has overestimated
   the expiration time of the cached response. End-to-end reload may be
   necessary if the cache entry has become corrupted for some reason.

   End-to-end revalidation may be requested either when the client does
   not have its own local cached copy, in which case we call it
   "unspecified end-to-end revalidation", or when the client does have a
   local cached copy, in which case we call it "specific end-to-end
   revalidation."

   The client can specify these three kinds of action using Cache-
   Control request directives:

   End-to-end reload
     The request includes a "no-cache" Cache-Control directive or, for
     compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
     names may be included with the no-cache directive in a request. The
     server MUST NOT use a cached copy when responding to such a
     request.

   Specific end-to-end revalidation
     The request includes a "max-age=0" Cache-Control directive, which
     forces each cache along the path to the origin server to revalidate
     its own entry, if any, with the next cache or server. The initial

     request includes a cache-validating conditional with the client's
     current validator.

   Unspecified end-to-end revalidation
     The request includes "max-age=0" Cache-Control directive, which
     forces each cache along the path to the origin server to revalidate
     its own entry, if any, with the next cache or server. The initial
     request does not include a cache-validating conditional; the first
     cache along the path (if any) that holds a cache entry for this
     resource includes a cache-validating conditional with its current
     validator.

   When an intermediate cache is forced, by means of a max-age=0
   directive, to revalidate its own cache entry, and the client has
   supplied its own validator in the request, the supplied validator may
   differ from the validator currently stored with the cache entry. In
   this case, the cache may use either validator in making its own
   request without affecting semantic transparency.

   However, the choice of validator may affect performance. The best
   approach is for the intermediate cache to use its own validator when
   making its request. If the server replies with 304 (Not Modified),
   then the cache should return its now validated copy to the client
   with a 200 (OK) response. If the server replies with a new entity and
   cache validator, however, the intermediate cache should compare the
   returned validator with the one provided in the client's request,
   using the strong comparison function. If the client's validator is
   equal to the origin server's, then the intermediate cache simply
   returns 304 (Not Modified). Otherwise, it returns the new entity with
   a 200 (OK) response.

   If a request includes the no-cache directive, it should not include
   min-fresh, max-stale, or max-age.

   In some cases, such as times of extremely poor network connectivity,
   a client may want a cache to return only those responses that it
   currently has stored, and not to reload or revalidate with the origin
   server. To do this, the client may include the only-if-cached
   directive in a request. If it receives this directive, a cache SHOULD
   either respond using a cached entry that is consistent with the other
   constraints of the request, or respond with a 504 (Gateway Timeout)
   status. However, if a group of caches is being operated as a unified
   system with good internal connectivity, such a request MAY be
   forwarded within that group of caches.

   Because a cache may be configured to ignore a server's specified
   expiration time, and because a client request may include a max-stale
   directive (which has a similar effect), the protocol also includes a

   mechanism for the origin server to require revalidation of a cache
   entry on any subsequent use. When the must-revalidate directive is
   present in a response received by a cache, that cache MUST NOT use
   the entry after it becomes stale to respond to a subsequent request
   without first revalidating it with the origin server. (I.e., the
   cache must do an end-to-end revalidation every time, if, based solely
   on the origin server's Expires or max-age value, the cached response
   is stale.)

   The must-revalidate directive is necessary to support reliable
   operation for certain protocol features. In all circumstances an
   HTTP/1.1 cache MUST obey the must-revalidate directive; in
   particular, if the cache cannot reach the origin server for any
   reason, it MUST generate a 504 (Gateway Timeout) response.

   Servers should send the must-revalidate directive if and only if
   failure to revalidate a request on the entity could result in
   incorrect operation, such as a silently unexecuted financial
   transaction.  Recipients MUST NOT take any automated action that
   violates this directive, and MUST NOT automatically provide an
   unvalidated copy of the entity if revalidation fails.

   Although this is not recommended, user agents operating under severe
   connectivity constraints may violate this directive but, if so, MUST
   explicitly warn the user that an unvalidated response has been
   provided.  The warning MUST be provided on each unvalidated access,
   and SHOULD require explicit user confirmation.

   The proxy-revalidate directive has the same meaning as the must-
   revalidate directive, except that it does not apply to non-shared
   user agent caches. It can be used on a response to an authenticated
   request to permit the user's cache to store and later return the
   response without needing to revalidate it (since it has already been
   authenticated once by that user), while still requiring proxies that
   service many users to revalidate each time (in order to make sure
   that each user has been authenticated). Note that such authenticated
   responses also need the public cache control directive in order to
   allow them to be cached at all.

14.9.5 No-Transform Directive

   Implementers of intermediate caches (proxies) have found it useful to
   convert the media type of certain entity bodies. A proxy might, for
   example, convert between image formats in order to save cache space
   or to reduce the amount of traffic on a slow link. HTTP has to date
   been silent on these transformations.

   Serious operational problems have already occurred, however, when
   these transformations have been applied to entity bodies intended for
   certain kinds of applications. For example, applications for medical
   imaging, scientific data analysis and those using end-to-end
   authentication, all depend on receiving an entity body that is bit
   for bit identical to the original entity-body.

   Therefore, if a response includes the no-transform directive, an
   intermediate cache or proxy MUST NOT change those headers that are
   listed in section 13.5.2 as being subject to the no-transform
   directive.  This implies that the cache or proxy must not change any
   aspect of the entity-body that is specified by these headers.

14.9.6 Cache Control Extensions

   The Cache-Control header field can be extended through the use of one
   or more cache-extension tokens, each with an optional assigned value.
   Informational extensions (those which do not require a change in
   cache behavior) may be added without changing the semantics of other
   directives. Behavioral extensions are designed to work by acting as
   modifiers to the existing base of cache directives. Both the new
   directive and the standard directive are supplied, such that
   applications which do not understand the new directive will default
   to the behavior specified by the standard directive, and those that
   understand the new directive will recognize it as modifying the
   requirements associated with the standard directive.  In this way,
   extensions to the Cache-Control directives can be made without
   requiring changes to the base protocol.

   This extension mechanism depends on a HTTP cache obeying all of the
   cache-control directives defined for its native HTTP-version, obeying
   certain extensions, and ignoring all directives that it does not
   understand.

   For example, consider a hypothetical new response directive called
   "community" which acts as a modifier to the "private" directive. We
   define this new directive to mean that, in addition to any non-shared
   cache, any cache which is shared only by members of the community
   named within its value may cache the response. An origin server
   wishing to allow the "UCI" community to use an otherwise private
   response in their shared cache(s) may do so by including

          Cache-Control: private, community="UCI"

   A cache seeing this header field will act correctly even if the cache
   does not understand the "community" cache-extension, since it will
   also see and understand the "private" directive and thus default to
   the safe behavior.

   Unrecognized cache-directives MUST be ignored; it is assumed that any
   cache-directive likely to be unrecognized by an HTTP/1.1 cache will
   be combined with standard directives (or the response's default
   cachability) such that the cache behavior will remain minimally
   correct even if the cache does not understand the extension(s).

14.10 Connection

   The Connection general-header field allows the sender to specify
   options that are desired for that particular connection and MUST NOT
   be communicated by proxies over further connections.

   The Connection header has the following grammar:

          Connection-header = "Connection" ":" 1#(connection-token)
          connection-token  = token

   HTTP/1.1 proxies MUST parse the Connection header field before a
   message is forwarded and, for each connection-token in this field,
   remove any header field(s) from the message with the same name as the
   connection-token. Connection options are signaled by the presence of
   a connection-token in the Connection header field, not by any
   corresponding additional header field(s), since the additional header
   field may not be sent if there are no parameters associated with that
   connection option.  HTTP/1.1 defines the "close" connection option
   for the sender to signal that the connection will be closed after
   completion of the response. For example,

          Connection: close

   in either the request or the response header fields indicates that
   the connection should not be considered `persistent' (section 8.1)
   after the current request/response is complete.

   HTTP/1.1 applications that do not support persistent connections MUST
   include the "close" connection option in every message.

14.11 Content-Base

   The Content-Base entity-header field may be used to specify the base
   URI for resolving relative URLs within the entity. This header field
   is described as Base in RFC 1808, which is expected to be revised.

          Content-Base      = "Content-Base" ":" absoluteURI

   If no Content-Base field is present, the base URI of an entity is
   defined either by its Content-Location (if that Content-Location URI
   is an absolute URI) or the URI used to initiate the request, in that

   order of precedence. Note, however, that the base URI of the contents
   within the entity-body may be redefined within that entity-body.