Appendix B. HTTP 与 MIME 的差异
HTTP/1.1 使用了许多为 Internet Message Format [RFC5322] 和 Multipurpose Internet Mail Extensions (MIME) [RFC2045] 定义的构造, 以允许消息体通过开放多样的表示形式和可扩展字段进行传输. 然而, 其中一些构造已被重新解释, 以更好地适应交互式通信的需求, 从而导致 MIME 构造在 HTTP 中的使用方式存在一些差异. 这些差异经过谨慎选择, 旨在优化二进制连接上的性能, 为新媒体类型的使用提供更大自由度, 简化日期比较, 并适应常见实现.
本附录描述 HTTP 与 MIME 不同的具体领域. 严格 MIME 环境与 HTTP 之间的代理和网关需要了解这些差异, 并在必要时提供适当转换.
B.1. MIME-Version
HTTP 不是符合 MIME 的协议. 然而, 消息可以包含单个 MIME-Version 头字段, 用于指示构造该消息时使用的 MIME 协议版本. 使用 MIME-Version 头字段表示该消息完全符合 MIME 协议 (如 [RFC2045] 所定义). 当把 HTTP 消息导出到严格 MIME 环境时, 发送方负责确保完全符合要求 (在可能的情况下).
B.2. 转换为规范形式
MIME 要求 Internet 邮件正文部件在传输之前转换为规范形式, 如 [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. 日期格式转换
HTTP/1.1 使用一组受限的日期格式 ([HTTP] 第 5.6.7 节) 来简化日期比较过程. 来自其他协议的代理和网关应当确保消息中存在的任何 Date 头字段符合 HTTP/1.1 格式之一, 并在必要时重写该日期.
B.4. Content-Encoding 的转换
MIME 不包含等价于 HTTP 的 Content-Encoding 头字段的任何概念. 由于该字段充当媒体类型的修饰符, 从 HTTP 到符合 MIME 的协议的代理和网关应当更改 Content-Type 头字段的值, 或在转发消息之前解码表示. (Internet 邮件中一些对 Content-Type 的实验性应用曾使用媒体类型参数 ";conversions=<content-coding>" 来执行等价于 Content-Encoding 的功能. 但是, 该参数并非 MIME 标准的一部分.)
B.5. Content-Transfer-Encoding 的转换
HTTP 不使用 MIME 的 Content-Transfer-Encoding 字段. 从符合 MIME 的协议到 HTTP 的代理和网关需要在向 HTTP 客户端递送响应消息之前移除任何 Content-Transfer-Encoding.
从 HTTP 到符合 MIME 的协议的代理和网关负责确保消息采用正确的格式和编码, 以便在该协议上安全传输; 其中 "安全传输" 由所用协议的限制定义. 如果转换并用适当的 Content-Transfer-Encoding 标记数据能够提高其在目标协议上安全传输的可能性, 这样的代理或网关应当这样做.
B.6. MHTML 和行长度限制
与 MHTML [RFC2557] 实现共享代码的 HTTP 实现需要了解 MIME 行长度限制. 由于 HTTP 没有此限制, HTTP 不会折叠长行. 通过 HTTP 传输的 MHTML 消息遵循 MHTML 的所有约定, 包括行长度限制和折叠, 规范化等, 因为 HTTP 传输 message-bodies 时不作修改, 并且除 "multipart/byteranges" 类型 ([HTTP] 第 14.6 节) 外, 不解释其中可能包含的内容或任何 MIME 头部行.