RFC 2068                        HTTP/1.1                    January 1997


19.4.6 Introduction of Transfer-Encoding

   HTTP/1.1 introduces the Transfer-Encoding header field (section
   14.40).  Proxies/gateways MUST remove any transfer coding prior to
   forwarding a message via a MIME-compliant protocol.

   A process for decoding the "chunked" transfer coding (section 3.6)
   can be represented in pseudo-code as:

          length := 0
          read chunk-size, chunk-ext (if any) and CRLF
          while (chunk-size > 0) {
             read chunk-data and CRLF
             append chunk-data to entity-body
             length := length + chunk-size
             read chunk-size and CRLF
          }
          read entity-header
          while (entity-header not empty) {
             append entity-header to existing header fields
             read entity-header
          }
          Content-Length := length
          Remove "chunked" from Transfer-Encoding

19.4.7 MIME-Version

   HTTP is not a MIME-compliant protocol (see appendix 19.4). However,
   HTTP/1.1 messages may include a single MIME-Version general-header
   field to indicate what version of the MIME protocol was used to
   construct the message. Use of the MIME-Version header field indicates
   that the message is in full compliance with the MIME protocol.
   Proxies/gateways are responsible for ensuring full compliance (where
   possible) when exporting HTTP messages to strict MIME environments.

          MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

   MIME version "1.0" is the default for use in HTTP/1.1. However,
   HTTP/1.1 message parsing and semantics are defined by this document
   and not the MIME specification.

19.5 Changes from HTTP/1.0

   This section summarizes major differences between versions HTTP/1.0
   and HTTP/1.1.






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


19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
       Addresses

   The requirements that clients and servers support the Host request-
   header, report an error if the Host request-header (section 14.23) is
   missing from an HTTP/1.1 request, and accept absolute URIs (section
   5.1.2) are among the most important changes defined by this
   specification.

   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
   addresses and servers; there was no other established mechanism for
   distinguishing the intended server of a request than the IP address
   to which that request was directed. The changes outlined above will
   allow the Internet, once older HTTP clients are no longer common, to
   support multiple Web sites from a single IP address, greatly
   simplifying large operational Web servers, where allocation of many
   IP addresses to a single host has created serious problems. The
   Internet will also be able to recover the IP addresses that have been
   allocated for the sole purpose of allowing special-purpose domain
   names to be used in root-level HTTP URLs. Given the rate of growth of
   the Web, and the number of servers already deployed, it is extremely
   important that all implementations of HTTP (including updates to
   existing HTTP/1.0 applications) correctly implement these
   requirements:

     o  Both clients and servers MUST support the Host request-header.

     o  Host request-headers are required in HTTP/1.1 requests.

     o  Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
        request does not include a Host request-header.

     o  Servers MUST accept absolute URIs.


















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