revised. The revisions may include some of the practices found in
   HTTP/1.0 but not in RFC 1521.

   This appendix describes specific areas where HTTP differs from RFC
   1521. Proxies and gateways to strict MIME environments should be
   aware of these differences and provide the appropriate conversions
   where necessary. Proxies and gateways from MIME environments to HTTP
   also need to be aware of the differences because some conversions may
   be required.

C.1  Conversion to Canonical Form

   RFC 1521 requires that an Internet mail entity be converted to
   canonical form prior to being transferred, as described in Appendix G
   of RFC 1521 [5]. Section 3.6.1 of this document describes the forms
   allowed for subtypes of the "text" media type when transmitted over
   HTTP.

   RFC 1521 requires that content with a Content-Type of "text"
   represent line breaks as CRLF and forbids the use of CR or LF outside
   of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
   indicate a line break within text content when a message is
   transmitted over HTTP.

   Where it is possible, a proxy or gateway from HTTP to a strict RFC
   1521 environment should translate all line breaks within the text
   media types described in Section 3.6.1 of this document to the RFC
   1521 canonical form of CRLF. Note, however, that this may be
   complicated by the presence of a Content-Encoding and by the fact
   that HTTP allows the use of some character sets which do not use
   octets 13 and 10 to represent CR and LF, as is the case for some
   multi-byte character sets.






 
RFC 1945                        HTTP/1.0                        May 1996


C.2  Conversion of Date Formats

   HTTP/1.0 uses a restricted set of date formats (Section 3.3) to
   simplify the process of date comparison. Proxies and gateways from
   other protocols should ensure that any Date header field present in a
   message conforms to one of the HTTP/1.0 formats and rewrite the date
   if necessary.

C.3  Introduction of Content-Encoding

   RFC 1521 does not include any concept equivalent to HTTP/1.0's
   Content-Encoding header field. Since this acts as a modifier on the
   media type, proxies and gateways from HTTP to MIME-compliant
   protocols must either change the value of the Content-Type header
   field or decode the Entity-Body before forwarding the message. (Some
   experimental applications of Content-Type for Internet mail have used
   a media-type parameter of ";conversions=<content-coding>" to perform
   an equivalent function as Content-Encoding. However, this parameter
   is not part of RFC 1521.)

C.4  No Content-Transfer-Encoding

   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
   1521. Proxies and gateways from MIME-compliant protocols to HTTP must
   remove any non-identity CTE ("quoted-printable" or "base64") encoding
   prior to delivering the response message to an HTTP client.

   Proxies and gateways from HTTP to MIME-compliant protocols are
   responsible for ensuring that the message is in the correct format
   and encoding for safe transport on that protocol, where "safe
   transport" is defined by the limitations of the protocol being used.
   Such a proxy or gateway should label the data with an appropriate
   Content-Transfer-Encoding if doing so will improve the likelihood of
   safe transport over the destination protocol.

C.5  HTTP Header Fields in Multipart Body-Parts

   In RFC 1521, most header fields in multipart body-parts are generally
   ignored unless the field name begins with "Content-". In HTTP/1.0,
   multipart body-parts may contain any HTTP header fields which are
   significant to the meaning of that part.

D.  Additional Features

   This appendix documents protocol elements used by some existing HTTP
   implementations, but not consistently and correctly across most
   HTTP/1.0 applications. Implementors should be aware of these
   features, but cannot rely upon their presence in, or interoperability




 
RFC 1945                        HTTP/1.0                        May 1996


   with, other HTTP/1.0 applications.