Content-Transfer-Encoding 是 HTTP 标头吗? [英] Is Content-Transfer-Encoding an HTTP header?
问题描述
我正在编写一个返回 base64 编码的 PDF 文件的 Web 服务，所以我的计划是在响应中添加两个标头:
I'm writing a web service that returns a base64-encoded PDF file, so my plan is to add two headers to the response:
Content-Type: application/pdf
Content-Transfer-Encoding: base64
我的问题是:Content-Transfer-Encoding 是有效的 HTTP 标头吗?我认为它可能只适用于 MIME.如果不是，我应该如何制作我的 HTTP 响应来表示我正在返回一个 base64 编码的 PDF 的事实?谢谢.
My question is: Is Content-Transfer-Encoding a valid HTTP header? I think it might only be for MIME. If not, how should I craft my HTTP response to represent the fact that I'm returning a base64-encoded PDF? Thanks.
看起来 HTTP 不支持此标头.来自 RFC2616 第 14 节:
It looks like HTTP does not support this header. From RFC2616 Section 14:
注意:虽然 Content-MD5 的定义与 HTTP 完全相同就像在 RFC 1864 中的 MIME 实体一样，有几种方法可以Content-MD5 对 HTTP 实体的应用不同于它的应用于 MIME 实体.一是 HTTP 与 MIME 不同，它确实不使用 Content-Transfer-Encoding，并使用 Transfer-Encoding 和内容编码.
Note: while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding.
关于我应该将标题设置为什么的任何想法?谢谢.
Any ideas for what I should set my headers to? Thanks.
编辑 2
在这个 PHP 参考手册页的注释中找到的许多代码示例似乎表明它实际上 是一个有效的 HTTP 标头:
Many of the code samples found in the comments of this PHP reference manual page seem to suggest that it actually is a valid HTTP header:
http://php.net/manual/en/function.header.php
推荐答案
Content-Transfer-Encoding 头域，可用于指定应用于数据的辅助编码，以便允许它通过可能具有的邮件传输机制数据或字符集限制.
A Content-Transfer-Encoding header field, which can be used to specify an auxiliary encoding that was applied to the data in order to allow it to pass through mail transport mechanisms which may have data or character set limitations.
及以后:
许多可以通过电子邮件有效传输的内容类型以它们的自然"表示.格式，为 8 位字符或二进制数据.此类数据无法通过某种传输方式传输协议.例如，RFC 821 将邮件消息限制为 7 位具有 1000 个字符行的 US-ASCII 数据.
Many Content-Types which could usefully be transported via email are represented, in their "natural" format, as 8-bit character or binary data. Such data cannot be transmitted over some transport protocols. For example, RFC 821 restricts mail messages to 7-bit US-ASCII data with 1000 character lines.
因此，有必要定义一个标准机制将此类数据重新编码为 7 位短线格式.(...) 这Content-Transfer-Encoding 字段用于指示类型用于表示身体的变换以可接受的运输方式.
It is necessary, therefore, to define a standard mechanism for re-encoding such data into a 7-bit short-line format. (...) The Content-Transfer-Encoding field is used to indicate the type of transformation that has been used in order to represent the body in an acceptable manner for transport.
由于您有一个与电子邮件毫无共同之处的网络服务，因此您不应使用此标头.
Since you have a webservice, which has nothing in common with emails, you shouldn't use this header.
您可以使用 Content-Encoding 标头指示传输的数据已被压缩(gzip 值).
You can use Content-Encoding header which indicates that transferred data has been compressed (gzip value).
我认为在你的情况下
Content-Type: application/pdf
就够了.此外，您可以设置 Content-Length 标头，但在我看来，如果您正在构建 web 服务(它不是 http 服务器/代理服务器) Content-Type 就足够了.请记住，如果使用不当，某些特定的标头(例如 Transfer-Encoding)可能会导致意外的通信问题，因此如果您不能 100% 确定某些标头的使用 - 如果您真的需要不管它与否 - 只是不要使用它.
is enough. Additionally, you can set Content-Length header, but in my opinion, if you are building webservice (it's not http server / proxy server) Content-Type is enough. Please bear in mind that some specific headers (e.g. Transfer-Encoding) if not used appropriately, may cause unexpected communication issues, so if you are not 100% sure about usage of some header - if you really need it or not - just don't use it.
这篇关于Content-Transfer-Encoding 是 HTTP 标头吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
