14.36.2 Range Retrieval Requests

   HTTP retrieval requests using conditional or unconditional GET
   methods may request one or more sub-ranges of the entity, instead of
   the entire entity, using the Range request header, which applies to
   the entity returned as the result of the request:

         Range = "Range" ":" ranges-specifier

   A server MAY ignore the Range header. However, HTTP/1.1 origin
   servers and intermediate caches SHOULD support byte ranges when
   possible, since Range supports efficient recovery from partially
   failed transfers, and supports efficient partial retrieval of large
   entities.

   If the server supports the Range header and the specified range or
   ranges are appropriate for the entity:

     o  The presence of a Range header in an unconditional GET modifies
        what is returned if the GET is otherwise successful. In other
        words, the response carries a status code of 206 (Partial
        Content) instead of 200 (OK).

     o  The presence of a Range header in a conditional GET (a request
        using one or both of If-Modified-Since and If-None-Match, or
        one or both of If-Unmodified-Since and If-Match) modifies what
        is returned if the GET is otherwise successful and the condition
        is true. It does not affect the 304 (Not Modified) response
        returned if the conditional is false.

   In some cases, it may be more appropriate to use the If-Range header
   (see section 14.27) in addition to the Range header.

   If a proxy that supports ranges receives a Range request, forwards
   the request to an inbound server, and receives an entire entity in
   reply, it SHOULD only return the requested range to its client. It
   SHOULD store the entire received response in its cache, if that is
   consistent with its cache allocation policies.






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


14.37 Referer

   The Referer[sic] request-header field allows the client to specify,
   for the server's benefit, the address (URI) of the resource from
   which the Request-URI was obtained (the "referrer", although the
   header field is misspelled.) The Referer request-header allows a
   server to generate lists of back-links to resources for interest,
   logging, optimized caching, etc. It also allows obsolete or mistyped
   links to be traced for maintenance. The Referer field MUST NOT be
   sent if the Request-URI was obtained from a source that does not have
   its own URI, such as input from the user keyboard.

        Referer        = "Referer" ":" ( absoluteURI | relativeURI )

   Example:

        Referer: http://www.w3.org/hypertext/DataSources/Overview.html

   If the field value is a partial URI, it SHOULD be interpreted
   relative to the Request-URI. The URI MUST NOT include a fragment.

     Note: Because the source of a link may be private information or
     may reveal an otherwise private information source, it is strongly
     recommended that the user be able to select whether or not the
     Referer field is sent. For example, a browser client could have a
     toggle switch for browsing openly/anonymously, which would
     respectively enable/disable the sending of Referer and From
     information.

14.38 Retry-After

   The Retry-After response-header field can be used with a 503 (Service
   Unavailable) response to indicate how long the service is expected to
   be unavailable to the requesting client. The value of this field can
   be either an HTTP-date or an integer number of seconds (in decimal)
   after the time of the response.

          Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

   Two examples of its use are

          Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
          Retry-After: 120

   In the latter example, the delay is 2 minutes.






Fielding, et. al.           Standards Track                   [Page 131]