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.





Fielding, et. al.           Standards Track                    [Page 99]

RFC 2068                        HTTP/1.1                    January 1997


   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.



Fielding, et. al.           Standards Track                   [Page 100]

RFC 2068                        HTTP/1.1                    January 1997


          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.