"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 MIME
   environment SHOULD translate all line breaks within the text media
   types described in section 3.7.1 of this document to the MIME
   canonical form of CRLF. Note, however, that this may be complicated
   by the presence of a Content-Encoding and by the fact that HTTP




 
RFC 2068                        HTTP/1.1                    January 1997


   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.

19.4.2 Conversion of Date Formats

   HTTP/1.1 uses a restricted set of date formats (section 3.3.1) 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.1 formats and rewrite the date
   if necessary.

19.4.3 Introduction of Content-Encoding

   MIME does not include any concept equivalent to HTTP/1.1'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
   MIME.)

19.4.4 No Content-Transfer-Encoding

   HTTP does not use the Content-Transfer-Encoding (CTE) field of MIME.
   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.

19.4.5 HTTP Header Fields in Multipart Body-Parts

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







 
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