19.4 Differences Between HTTP Entities and MIME Entities
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
822) and the Multipurpose Internet Mail Extensions (MIME ) to allow
entities to be transmitted in an open variety of representations and
with extensible mechanisms. However, MIME [7] discusses mail, and
HTTP has a few features that are different from those described in
MIME. These differences were carefully chosen to optimize
performance over binary connections, to allow greater freedom in the
use of new media types, to make date comparisons easier, and to
acknowledge the practice of some early HTTP servers and clients.
This appendix describes specific areas where HTTP differs from MIME.
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.
19.4.1 Conversion to Canonical Form
MIME requires that an Internet mail entity be converted to canonical
form prior to being transferred. Section 3.7.1 of this document
describes the forms allowed for subtypes of the "text" media type
when transmitted over HTTP. MIME requires that content with a 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 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
Fielding, et. al. Standards Track [Page 152]
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=" 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.
Fielding, et. al. Standards Track [Page 153]