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