Appendix A. Differences between HTTP and MIME (HTTP与MIME的差异)
HTTP/1.1使用了为互联网消息格式[RFC5322]和多用途互联网邮件扩展(MIME)[RFC2045]定义的许多结构，以允许以多种开放的表示形式传输消息体，并具有可扩展的头字段。然而，RFC 2045仅关注电子邮件; HTTP应用程序具有许多与电子邮件不同的特性; 因此，HTTP具有与MIME不同的特性。这些差异经过仔细选择，以优化二进制连接的性能，允许在使用新媒体类型时有更大的自由度，使日期比较更容易，并承认一些早期HTTP服务器和客户端的实践。
本附录描述了HTTP与MIME不同的具体领域。与严格MIME环境之间的代理和网关需要了解这些差异，并在必要时提供适当的转换。
A.1. MIME-Version
HTTP不是符合MIME的协议。但是，消息可以包含单个MIME-Version头字段，以指示用于构造消息的MIME协议的版本。使用MIME-Version头字段表示消息完全符合MIME协议(如[RFC2045]中定义)。在将HTTP消息导出到严格的MIME环境时，发送方负责确保完全符合(在可能的情况下)。
A.2. Conversion to Canonical Form (转换为规范形式)
MIME要求在传输之前将互联网邮件正文部分转换为规范形式，如[RFC2049]第4节所述。本文档第3.1.1.3节描述了通过HTTP传输时"text"媒体类型的子类型允许的形式。[RFC2046]要求类型为"text"的内容将换行表示为CRLF，并禁止在换行序列之外使用CR或LF。HTTP允许CRLF、单独的CR和单独的LF来指示文本内容中的换行。
从HTTP到严格MIME环境的代理或网关应该将本文档第3.1.1.3节中描述的文本媒体类型中的所有换行转换为RFC 2049规范形式的CRLF。但是请注意，这可能会因Content-Encoding的存在以及HTTP允许使用一些不使用八位字节13和10分别表示CR和LF的字符集而变得复杂。
转换将破坏应用于原始内容的任何加密校验和，除非原始内容已经是规范形式。因此，对于在HTTP中使用此类校验和的任何内容，建议使用规范形式。
A.3. Conversion of Date Formats (日期格式的转换)
HTTP/1.1使用一组受限的日期格式(第7.1.1.1节)来简化日期比较过程。来自其他协议的代理和网关应该确保消息中存在的任何Date头字段符合HTTP/1.1格式之一，并在必要时重写日期。
A.4. Conversion of Content-Encoding (Content-Encoding的转换)
MIME不包括与HTTP/1.1的Content-Encoding头字段等效的任何概念。由于这充当媒体类型的修饰符，从HTTP到符合MIME的协议的代理和网关应该更改Content-Type头字段的值或在转发消息之前解码表示。(一些Content-Type在互联网邮件中的实验性应用程序使用了";conversions=<content-coding>"的媒体类型参数来执行与Content-Encoding等效的功能。但是，此参数不是MIME标准的一部分)。
A.5. Conversion of Content-Transfer-Encoding (Content-Transfer-Encoding的转换)
HTTP不使用MIME的Content-Transfer-Encoding字段。从符合MIME的协议到HTTP的代理和网关需要在将响应消息传递给HTTP客户端之前删除任何Content-Transfer-Encoding。
从HTTP到符合MIME的协议的代理和网关负责确保消息采用正确的格式和编码，以在该协议上安全传输，其中"安全传输"由所使用协议的限制定义。如果这样做能够提高通过目标协议安全传输的可能性，则此类代理或网关应该使用适当的Content-Transfer-Encoding转换和标记数据。
A.6. MHTML and Line Length Limitations (MHTML和行长度限制)
与MHTML[RFC2557]实现共享代码的HTTP实现需要了解MIME行长度限制。由于HTTP没有此限制，因此HTTP不会折叠长行。通过HTTP传输的MHTML消息遵循MHTML的所有约定，包括行长度限制和折叠、规范化等，因为HTTP将消息体作为有效负载传输，并且除了"multipart/byteranges"类型([RFC7233]的附录A)之外，不解释可能包含在其中的内容或任何MIME头行。
返回: RFC 7231 目录