Content-Transfer-Encoding是一个HTTP头？

Question

我正在编写一个返回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的实体主体的RFC 1864完全相同,但Content-MD5到HTTP实体主体的应用程序有几种不同于其应用程序的MIME实体 - 身体.一个是,与MIME不同,HTTP不使用Content-Transfer-Encoding,并且使用Transfer-Encoding和Content-Encoding.

我应该设置标题的任何想法？谢谢.

编辑2

在这个PHP参考手册页的注释中找到的许多代码示例似乎表明它实际上是一个有效的HTTP头:

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

Answer 1

根据RFC 1341(RFC 2045废弃):

Content-Transfer-Encoding标头字段,可用于指定应用于数据的辅助编码,以允许它通过可能具有数据或字符集限制的邮件传输机制.

然后:

可以通过电子邮件传输的许多内容类型以其"自然"格式表示为8位字符或二进制数据.这些数据不能通过某些传输协议传输.例如,RFC 821将邮件消息限制为具有1000个字符行的7位US-ASCII数据.

因此,有必要定义一种标准机制,用于将这种数据重新编码为7位短线格式.(...)Content-Transfer-Encoding字段用于指示为了以可接受的传输方式表示身体而使用的转换类型.

由于您的网络服务与电子邮件没有任何共同之处,因此您不应使用此标头.

您可以使用Content-Encoding表示已传输数据已压缩的标头(gzip值).

我认为在你的情况下

Content-Type: application/pdf

足够.此外,您可以设置Content-Length标题,但在我看来,如果您正在构建webservice(它不是http服务器/代理服务器)Content-Type就足够了.请记住,一些特定的标题(例如Transfer-Encoding)如果使用不当,可能会导致意外的通信问题,所以如果你不是100%确定使用某些标题 - 如果你真的需要或不 - 请不要使用它.