If-Range (section 14.27) header fields. The definition of how they
   are used and compared as cache validators is in section 13.3.3. An
   entity tag consists of an opaque quoted string, possibly prefixed by
   a weakness indicator.

         entity-tag = [ weak ] opaque-tag

         weak       = "W/"
         opaque-tag = quoted-string

   A "strong entity tag" may be shared by two entities of a resource
   only if they are equivalent by octet equality.

   A "weak entity tag," indicated by the "W/" prefix, may be shared by
   two entities of a resource only if the entities are equivalent and
   could be substituted for each other with no significant change in
   semantics. A weak entity tag can only be used for weak comparison.

   An entity tag MUST be unique across all versions of all entities
   associated with a particular resource. A given entity tag value may
   be used for entities obtained by requests on different URIs without
   implying anything about the equivalence of those entities.




 
RFC 2068                        HTTP/1.1                    January 1997


3.12 Range Units

   HTTP/1.1 allows a client to request that only part (a range of) the
   response entity be included within the response. HTTP/1.1 uses range
   units in the Range (section 14.36) and Content-Range (section 14.17)
   header fields. An entity may be broken down into subranges according
   to various structural units.

         range-unit       = bytes-unit | other-range-unit

         bytes-unit       = "bytes"
         other-range-unit = token

The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
   implementations may ignore ranges specified using other units.
   HTTP/1.1 has been designed to allow implementations of applications
   that do not depend on knowledge of ranges.

4 HTTP Message

4.1 Message Types

   HTTP messages consist of requests from client to server and responses
   from server to client.

          HTTP-message   = Request | Response     ; HTTP/1.1 messages

   Request (section 5) and Response (section 6) messages use the generic
   message format of RFC 822 [9] for transferring entities (the payload
   of the message). Both types of message consist of a start-line, one
   or more header fields (also known as "headers"), an empty line (i.e.,
   a line with nothing preceding the CRLF) indicating the end of the
   header fields, and an optional message-body.

           generic-message = start-line
                             *message-header
                             CRLF
                             [ message-body ]

           start-line      = Request-Line | Status-Line

   In the interest of robustness, servers SHOULD ignore any empty
   line(s) received where a Request-Line is expected. In other words, if
   the server is reading the protocol stream at the beginning of a
   message and receives a CRLF first, it should ignore the CRLF.







 
RFC 2068                        HTTP/1.1                    January 1997


     Note: certain buggy HTTP/1.0 client implementations generate an
     extra CRLF's after a POST request. To restate what is explicitly
     forbidden by the BNF, an HTTP/1.1 client must not preface or follow
     a request with an extra CRLF.

4.2 Message Headers

   HTTP header fields, which include general-header (section 4.5),
   request-header (section 5.3), response-header (section 6.2), and
   entity-header (section 7.1) fields, follow the same generic format as
   that given in Section 3.1 of RFC 822 [9]. Each header field consists
   of a name followed by a colon (":") and the field value. Field names
   are case-insensitive. The field value may be preceded by any amount
   of LWS, though a single SP is preferred. Header fields can be