内容传输编码是HTTP头吗？

Question

内容传输编码是HTTP头吗？

53

我正在编写一个返回base64编码的PDF文件的Web服务，因此我的计划是在响应中添加两个头部:

Content-Type: application/pdf
Content-Transfer-Encoding: base64

我的问题是：是否Content-Transfer-Encoding是有效的HTTP标头？我认为它可能只适用于MIME。如果不是，我应该如何制作我的HTTP响应以表示我正在返回一个base64编码的PDF？谢谢。

编辑：

看起来HTTP不支持此标头。从RFC2616第14节：

请注意：虽然Content-MD5的定义对于HTTP与MIME实体主体完全相同，但是在将Content-MD5应用于HTTP实体主体方面，有几种方式与将Content-MD5应用于MIME实体主体不同。其中之一是HTTP不像MIME那样使用Content-Transfer-Encoding，而是使用Transfer-Encoding和Content-Encoding。

有什么想法可以设置我的标头吗？谢谢。

编辑2

在此PHP参考手册页面的评论中找到的许多代码示例似乎表明它实际上是有效的HTTP标头：

http://php.net/manual/en/function.header.php

- Michael

4

为什么您想要进行Base64编码呢？ - Julian Reschke

3

我不知道，我只是被分配了这个项目。它目前正在生产中，所以消费者希望它表现出这样的行为。 - Michael

2

这不是一个HTTP头字段，UAs会忽略它，也没有使用base64编码的必要；HTTP允许二进制传输。 - Julian Reschke

5

没有必要进行base64编码；HTTP允许二进制负载，因此在HTTP中不存在Content-Transfer-Encoding。 - Julian Reschke

6

@Potaswatter说：“网络浏览器几十年来一直没有二进制数据的问题，否则它们就不会显示GIF和JPG图像。” - Julian Reschke

显示剩余7条评论

3个回答

1

在rfc2616第14.15节中的注释非常明确: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

"注意：虽然Content-MD5的定义对于HTTP与RFC 1864的MIME实体正文完全相同，但是在将Content-MD5应用于HTTP实体正文时，有几种方式与将其应用于MIME实体正文不同。 其中一个区别是HTTP不像MIME那样使用Content-Transfer-Encoding，而是使用Transfer-Encoding和Content-Encoding。另一个区别是HTTP更频繁地使用二进制内容类型而不是MIME，因此值得注意的是，在这种情况下，用于计算摘要的字节顺序是为该类型定义的传输字节顺序。最后，HTTP允许以任何几种换行约定之一而不仅仅是使用CRLF的规范形式传输文本类型。"

- Pat P

0

正如之前已经回答过并且在这里，有效的Content-Transfer-Encoding HTTP响应头不存在。同时，已知的头部Content-Encoding和Transfer-Encoding没有适当的值来表达Base64编码的响应体。

从这里开始，没有客户端会期望一个声明为application/pdf的响应被编码为Base64！如果你想这样做，最好使用不同的内容类型，比如：

Content-Type: application/pdf+base64

在这种情况下，客户端会知道一些Base64编码的数据即将到来（基本子类型是加号后缀），并且有一个提示里面有PDF。

即使这有点hacky（+base64不是官方媒体类型后缀official media type suffix），但至少会在某种程度上符合一些标准。最好使用自定义内容类型而不是滥用标准的HTTP头！

当然，任何浏览器都无法直接打开这样的响应。也许您的项目应该考虑创建另一个端点，提供一个二进制PDF响应，并将此响应标记为已弃用。

- Arne Burmeister

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- omnomnom · Accepted Answer

根据RFC 1341（已被RFC 2045取代）：

引用：内容传输编码头字段可以用于指定辅助编码，以使数据通过可能具有数据或字符集限制的邮件传输机制。

稍后又提到：

可以通过电子邮件传输许多 Content-Type，这些类型以其“自然”格式表示为8位字符或二进制数据。这样的数据无法通过某些传输协议传输。例如，RFC 821将邮件消息限制为带有1000个字符行的7位US-ASCII数据。

因此，需要定义一种标准机制，将此类数据重新编码为7位短行格式。 Content-Transfer-Encoding字段用于指示已使用的转换类型，以便以可接受的方式传输正文。

由于您拥有与电子邮件无关的Web服务，因此不应使用此标题。

您可以使用Content-Encoding标题，该标题指示传输的数据已经过压缩（gzip值）。

我认为在您的情况下，

Content-Type: application/pdf

足够了。此外，您可以设置Content-Length标头，但我认为，如果您正在构建webservice（它不是http服务器/代理服务器），则Content-Type就足够了。请记住，某些特定的标头（例如Transfer-Encoding）如果未正确使用，可能会导致意外的通信问题，因此如果您对某个标头的使用不确定，请不要使用它。