3. If a Content-Length header field (section 14.14) is present, its
     value in bytes represents the length of the message-body.

   4. If the message uses the media type "multipart/byteranges", which is
     self-delimiting, then that defines the length. This media type MUST
     NOT be used unless the sender knows that the recipient can parse it;
     the presence in a request of a Range header with multiple byte-range
     specifiers implies that the client can parse multipart/byteranges
     responses.

   5. By the server closing the connection. (Closing the connection
     cannot be used to indicate the end of a request body, since that
     would leave no possibility for the server to send back a response.)

   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
   containing a message-body MUST include a valid Content-Length header
   field unless the server is known to be HTTP/1.1 compliant. If a
   request contains a message-body and a Content-Length is not given,
   the server SHOULD respond with 400 (bad request) if it cannot
   determine the length of the message, or with 411 (length required) if
   it wishes to insist on receiving a valid Content-Length.

   All HTTP/1.1 applications that receive entities MUST accept the
   "chunked" transfer coding (section 3.6), thus allowing this mechanism
   to be used for messages when the message length cannot be determined
   in advance.

   Messages MUST NOT include both a Content-Length header field and the
   "chunked" transfer coding. If both are received, the Content-Length
   MUST be ignored.

   When a Content-Length is given in a message where a message-body is
   allowed, its field value MUST exactly match the number of OCTETs in
   the message-body. HTTP/1.1 user agents MUST notify the user when an
   invalid length is received and detected.















 
RFC 2068                        HTTP/1.1                    January 1997


4.5 General Header Fields

   There are a few header fields which have general applicability for
   both request and response messages, but which do not apply to the
   entity being transferred. These header fields apply only to the
   message being transmitted.

          general-header = Cache-Control            ; Section 14.9
                         | Connection               ; Section 14.10
                         | Date                     ; Section 14.19
                         | Pragma                   ; Section 14.32
                         | Transfer-Encoding        ; Section 14.40
                         | Upgrade                  ; Section 14.41
                         | Via                      ; Section 14.44

   General-header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields may be given the semantics of general
   header fields if all parties in the communication recognize them to
   be general-header fields.  Unrecognized header fields are treated as
   entity-header fields.

5 Request

   A request message from a client to a server includes, within the
   first line of that message, the method to be applied to the resource,
   the identifier of the resource, and the protocol version in use.

           Request       = Request-Line              ; Section 5.1
                           *( general-header         ; Section 4.5
                            | request-header         ; Section 5.3
                            | entity-header )        ; Section 7.1
                           CRLF
                           [ message-body ]          ; Section 7.2

5.1 Request-Line

   The Request-Line begins with a method token, followed by the
   Request-URI and the protocol version, and ending with CRLF. The
   elements are separated by SP characters. No CR or LF are allowed
   except in the final CRLF sequence.

          Request-Line   = Method SP Request-URI SP HTTP-Version CRLF