Appendix A. HTTP 与 MIME 的差异
HTTP/1.1 使用 Internet Message Format [RFC5322] 和 Multipurpose Internet Mail Extensions (MIME) [RFC2045] 中定义的许多构造, 以允许 message body 通过开放多样的表示传输, 并使用可扩展的 header fields. 然而, RFC 2045 只关注电子邮件; HTTP 应用具有许多不同于电子邮件的特征; 因此, HTTP 具有不同于 MIME 的特性. 这些差异经过谨慎选择, 用于优化二进制连接上的性能, 允许在使用新 media types 时具有更大的自由度, 简化日期比较, 并承认一些早期 HTTP 服务器和客户端的实践.
本附录描述 HTTP 与 MIME 存在差异的具体领域. 往返严格 MIME 环境的代理和网关需要了解这些差异, 并在必要时提供适当转换.
A.1. MIME-Version
HTTP 不是符合 MIME 的协议. 然而, 消息可以包含单个 MIME-Version header field, 用于指示构造该消息时使用的 MIME 协议版本. 使用 MIME-Version header field 表明该消息完全符合 MIME 协议 (如 [RFC2045] 所定义). 发送方在将 HTTP 消息导出到严格 MIME 环境时, 负责确保其完全符合要求 (在可能的情况下).
A.2. 转换为规范形式
MIME 要求 Internet mail body part 在传输前转换为规范形式, 如 [RFC2049] 的 Section 4 所述. 本文档的 Section 3.1.1.3 描述了通过 HTTP 传输时 "text" media type 子类型所允许的形式. [RFC2046] 要求类型为 "text" 的内容使用 CRLF 表示换行, 并禁止在换行序列之外使用 CR 或 LF.HTTP 允许 CRLF, 裸 CR 和裸 LF 表示文本内容中的换行.
从 HTTP 到严格 MIME 环境的代理或网关, 应将本文档 Section 3.1.1.3 中描述的 text media types 内的所有换行转换为 RFC 2049 的 CRLF 规范形式. 但请注意, Content-Encoding 的存在以及 HTTP 允许使用某些不分别用 octets 13 和 10 表示 CR 与 LF 的 charsets, 可能会使这一点变得复杂.
除非原始内容已经采用规范形式, 否则转换会破坏应用于原始内容的任何加密校验和. 因此, 对于在 HTTP 中使用此类校验和的任何内容, 推荐使用规范形式.
A.3. 日期格式转换
HTTP/1.1 使用一组受限的日期格式 (Section 7.1.1.1), 以简化日期比较过程. 来自其他协议的代理和网关应确保消息中存在的任何 Date header field 符合 HTTP/1.1 格式之一, 并在必要时重写日期.
A.4. Content-Encoding 的转换
MIME 不包含任何等价于 HTTP/1.1 的 Content-Encoding header field 的概念. 由于它作为 media type 的修饰符, 从 HTTP 到符合 MIME 协议的代理和网关应在转发消息前更改 Content-Type header field 的值, 或解码该表示.(一些 Internet mail 的实验性 Content-Type 应用曾使用 media-type 参数 ";conversions=<content-coding>" 来执行等价于 Content-Encoding 的功能. 然而, 该参数并非 MIME 标准的一部分).
A.5. Content-Transfer-Encoding 的转换
HTTP 不使用 MIME 的 Content-Transfer-Encoding 字段. 从符合 MIME 协议到 HTTP 的代理和网关, 需要在向 HTTP 客户端交付响应消息之前移除任何 Content-Transfer-Encoding.
从 HTTP 到符合 MIME 协议的代理和网关, 负责确保消息采用适合在该协议上安全传输的正确格式和编码, 其中 "safe transport" 由所用协议的限制来定义. 如果这样做能够提高在目标协议上安全传输的可能性, 这类代理或网关应使用适当的 Content-Transfer-Encoding 转换并标记数据.
A.6. MHTML 与行长度限制
与 MHTML [RFC2557] 实现共享代码的 HTTP 实现需要了解 MIME 的行长度限制. 由于 HTTP 没有这种限制, HTTP 不折叠长行. 由 HTTP 传输的 MHTML 消息遵循 MHTML 的所有约定, 包括行长度限制和折叠, 规范化等, 因为 HTTP 将所有 message-bodies 作为 payload 传输, 并且除了 "multipart/byteranges" 类型 ([RFC7233] 的 Appendix A) 外, 不解释其中可能包含的内容或任何 MIME header lines.