我正在编写一个返回base64编码的PDF文件的Web服务，所以我的计划是在响应中添加两个标题：
Content-Type: application/pdf
Content-Transfer-Encoding: base64
我的问题是：Content-Transfer-Encoding是否是有效的HTTP标头？我认为它可能只适用于MIME。如果没有，我应该如何制作我的HTTP响应以表示我正在返回base64编码的PDF？感谢。
编辑：
看起来HTTP不支持此标头。来自RFC2616 Section 14：
注意：虽然Content-MD5的定义与HTTP完全相同 与RFC实体主体的RFC 1864一样，有几种方法可供选择 Content-MD5对HTTP实体主体的应用与其不同 应用于MIME实体。一个是 HTTP，与MIME不同 不使用Content-Transfer-Encoding ，并使用Transfer-Encoding和 内容编码。
我应该设置标题的任何想法？感谢。
编辑2
在本PHP参考手册页的注释中找到的许多代码示例似乎都表明它实际上 是一个有效的HTTP头：
答案 0 :(得分：26)
Content-Transfer-Encoding标头字段，可用于 指定应用于数据的辅助编码 允许它通过可能有的邮件传输机制 数据或字符集限制。
以后：
许多内容类型可以通过电子邮件进行有效传输 以“自然”格式表示为8位字符或 二进制数据。这些数据不能通过某种传输方式传输 协议。例如，RFC 821将邮件限制为7位 带有1000个字符行的US-ASCII数据。
因此，有必要为其定义标准机制 将这些数据重新编码为7位短线格式。 （...） Content-Transfer-Encoding字段用于指示其类型 为了代表身体而使用的变换 以可接受的方式运输。
由于您的网络服务与电子邮件没有任何共同之处，因此您不应使用此标头。
您可以使用Content-Encoding标题表示已传输的数据已被压缩（gzip值）。
我认为在你的情况下
Content-Type: application/pdf
就够了。此外，您可以设置Content-Length标头，但在我看来，如果您正在构建webservice（它不是http服务器/代理服务器），Content-Type就足够了。请记住，一些特定的标题（例如Transfer-Encoding）如果使用不当，可能会导致意外的通信问题，所以如果你不是100％肯定使用某些标题 - 如果你真的需要或不 - 只是不要使用它。
答案 1 :(得分：0)
rfc2616第14.15节中的注释是明确的：https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
“注意：尽管Content-MD5的定义与 RFC 1864中的MIME实体使用HTTP，有几种方法 Content-MD5在HTTP实体中的应用 从它的应用到MIME实体，有所不同。 一个是 HTTP与MIME不同，它不使用Content-Transfer-Encoding ，并且 确实使用了传输编码和内容编码。另一个是 HTTP比MIME更频繁地使用二进制内容类型，因此 值得注意的是，在这种情况下，用于计算的字节顺序 摘要是为类型定义的传输字节顺序。 最后，HTTP允许通过以下几种方式传输文本类型 换行约定，而不仅仅是使用CRLF的规范形式。”
答案 2 :(得分：0)
正如之前和 here 所回答的那样，有效的 Content-Transfer-Encoding HTTP 响应标头不存在。此外，已知的标头 Content-Encoding 和 Transfer-Encoding 没有合适的值来表达 Base64 编码的响应正文。
从这里开始，没有客户端会期望声明为 application/pdf 的响应被编码为 Base64！如果您想这样做，最好使用不同的内容类型，例如：
Content-Type: application/pdf+base64
在这种情况下，客户端会知道一些 Base64 编码的数据即将到来（基本子类型是加号后面的后缀），并提示那里有 PDF。
即使这有点老套（+base64 不是 official media type suffix），但至少会以某种方式满足某些标准。使用自定义内容类型比滥用标准 HTTP 标头更好！
当然没有任何浏览器能够直接打开这样的响应。也许您的项目应该考虑创建另一个提供二进制 PDF 响应的端点并将其标记为已弃用。