带有 HTTP 的 MIME 的 Content-transfer-Encoding 标头答案

【问题标题】：Content-transfer-Encoding Header of MIME with HTTP带有 HTTP 的 MIME 的 Content-transfer-Encoding 标头
【发布时间】：2014-03-30 18:33:19
【问题描述】：

我对通过 HTTP 发送 mime 附件有疑问：

在 http 规范中引用了以下内容：

“C.4 无 Content-Transfer-Encoding：HTTP 不使用 RFC 1521 的 Content-Transfer-Encoding (CTE) 字段。从符合 MIME 的协议到 HTTP 的代理和网关必须删除任何非身份 CTE ( “quoted-printable”或“base64”）在将响应消息传递给 HTTP 客户端之前进行编码。从 HTTP 到 MIME 兼容协议的代理和网关负责确保消息采用正确的格式和编码，以便在该协议上进行安全传输，其中“安全传输”由所使用协议的限制定义。如果这样做可以提高通过目标协议进行安全传输的可能性，则此类代理或网关应使用适当的 Content-Transfer-Encoding 标记数据。”

这是否意味着专门针对仅通过 http 发送 MIME 附件，我们不应该将 content-transfer-encoding 指定为quoted-printable 或 base64 ？

另外，当我通过 JMS 或 Mail 等其他传输方式发送此类附件时，conetent-transfer-encoding 的行为是什么？例如在 SOAP over JMS 消息中？

还发现以下与 RFC 4130 相关：

“5.2.未使用的 MIME 标头和操作 5.2.1。 HTTP 传输中未使用内容传输编码 HTTP 可以处理二进制数据，因此不需要使用 MIME [1] 的内容传输编码。 [3] 第 19.4.5 节讨论了这种差异。然而，二进制或 8 位的内容传输编码值是允许的，但不是必需的。缺少此标头不得导致事务失败。还允许在 AS2 消息正文中对 MIME 正文部分进行内容传输编码。”

所以我基本上对特定于 HTTP 协议的 mime 附件的行为完全感到困惑，并希望澄清它的行为。

【问题讨论】：

标签： http mime

【解决方案1】：

HTTP 不是 MIME，它只是借鉴了 MIME 消息格式。 HTTP 中的有效负载是二进制的，根本没有 Content-Transfer-Encoding 标头字段。您可以指定它，但它的效果为零，并且会分散人们查看电线痕迹的注意力。

【讨论】：