entity-header  = Allow                    ; Section 14.7
                         | Content-Base             ; Section 14.11
                         | Content-Encoding         ; Section 14.12
                         | Content-Language         ; Section 14.13
                         | Content-Length           ; Section 14.14
                         | Content-Location         ; Section 14.15
                         | Content-MD5              ; Section 14.16
                         | Content-Range            ; Section 14.17
                         | Content-Type             ; Section 14.18
                         | ETag                     ; Section 14.20
                         | Expires                  ; Section 14.21
                         | Last-Modified            ; Section 14.29
                         | extension-header

          extension-header = message-header

   The extension-header mechanism allows additional entity-header fields
   to be defined without changing the protocol, but these fields cannot
   be assumed to be recognizable by the recipient. Unrecognized header
   fields SHOULD be ignored by the recipient and forwarded by proxies.

7.2 Entity Body

   The entity-body (if any) sent with an HTTP request or response is in
   a format and encoding defined by the entity-header fields.

          entity-body    = *OCTET

   An entity-body is only present in a message when a message-body is
   present, as described in section 4.3. The entity-body is obtained
   from the message-body by decoding any Transfer-Encoding that may have
   been applied to ensure safe and proper transfer of the message.

7.2.1 Type

   When an entity-body is included with a message, the data type of that
   body is determined via the header fields Content-Type and Content-
   Encoding. These define a two-layer, ordered encoding model:

          entity-body := Content-Encoding( Content-Type( data ) )

   Content-Type specifies the media type of the underlying data.
   Content-Encoding may be used to indicate any additional content
   codings applied to the data, usually for the purpose of data
   compression, that are a property of the requested resource. There is
   no default encoding.






 
RFC 2068                        HTTP/1.1                    January 1997


   Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URL used to identify the
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

7.2.2 Length

   The length of an entity-body is the length of the message-body after
   any transfer codings have been removed. Section 4.4 defines how the
   length of a message-body is determined.

8 Connections

8.1 Persistent Connections

8.1.1 Purpose

   Prior to persistent connections, a separate TCP connection was
   established to fetch each URL, increasing the load on HTTP servers
   and causing congestion on the Internet. The use of inline images and
   other associated data often requires a client to make multiple
   requests of the same server in a short amount of time. Analyses of
   these performance problems are available [30][27]; analysis and
   results from a prototype implementation are in [26].

   Persistent HTTP connections have a number of advantages:

     o  By opening and closing fewer TCP connections, CPU time is saved,
        and memory used for TCP protocol control blocks is also saved.
     o  HTTP requests and responses can be pipelined on a connection.
        Pipelining allows a client to make multiple requests without
        waiting for each response, allowing a single TCP connection to be
        used much more efficiently, with much lower elapsed time.
     o  Network congestion is reduced by reducing the number of packets
        caused by TCP opens, and by allowing TCP sufficient time to
        determine the congestion state of the network.
     o  HTTP can evolve more gracefully; since errors can be reported
        without the penalty of closing the TCP connection. Clients using
        future versions of HTTP might optimistically try a new feature, but