Is Content-Transfer-Encoding an HTTP header?

48
votes

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

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.

EDIT:

It looks like HTTP does not support this header. From RFC2616 Section 14:

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.

EDIT 2

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

3
httpbase64mime
Why do you want to base64-encode anyway? – Julian Reschke
I don't know, I was just given this project. It's currently in production, so this is how its consumers expect it to behave. – Michael
Well, it's not an HTTP header field, UAs ignore it, and there's really no use for base64 encoding; HTTP allows binary transfers. – Julian Reschke
There's no point in base64-encoding; HTTP allows binary payloads, and consequently Content-Transfer-Encoding doesn't exist in HTTP. – Julian Reschke
@Potaswatter: Web browsers haven't had problems with binary data for decades, otherwise they wouldn't display GIFs and JPGs. – Julian Reschke

3 Answers

32
votes

According to RFC 1341 (made obsolete by RFC 2045):

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.

and later:

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.

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.

You can use Content-Encoding header which indicates that transferred data has been compressed (gzip value).

I think that in your case 

Content-Type: application/pdf

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.

1
votes

Notes in rfc2616 section 14.15 are explicit: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

"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. Another is that HTTP more frequently uses binary content types than MIME, so it is worth noting that, in such cases, the byte order used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types with any of several line break conventions and not just the canonical form using CRLF."

0
votes

As been answered before and also here, a valid Content-Transfer-Encoding HTTP response header does not exist. Also the known headers Content-Encoding and Transfer-Encoding have no appropriate value to express a Base64 encoded response body.

Starting from here, no client would expect a response declared as application/pdf to be encoded as Base64! If you wand to do so, better use a different content type like:

Content-Type: application/pdf+base64

In this case, a client would know some Base64 encoded data is coming (the basic subtype is the suffix after the plus sign) and has a hint there is PDF in there.

Even this is a little hacky (+base64 is no official media type suffix) but at least would somehow meet some standards. Better use a custom content type than misusing standard HTTP headers!

Of course no browser would be able to directly open such a response anyway. Maybe your project should consider creating another endpoint offering a binary PDF response and marking this one deprecated.