I'm looking to see whether this is correct as an HTTP response header
Content-Type: application/pdf; charset=ISO-8859-1
or we should be emitting this instead
Content-Type: application/pdf
I believe the latter is correct, given this:
The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset
parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or
its subsets MUST be labeled with an appropriate charset value.
rfc2068 HTTP/1.1
And that rfc3778 The application/pdf Media Type doesn't mention charsets at all.
This SO discussion is where I started, but isn't specifically about application/pdf: Is it categorically wrong to send a charset parameter with a Content-Type header for non-text media types?
Can anyone confirm or deny or point me to a better RFC?
PDF built-in fonts are all Windows1252 character encoded. Almost all other fonts use the UTF-16 character set.
The Content-Type representation header is used to indicate the original media type of the resource (prior to any content encoding applied for sending). In responses, a Content-Type header provides the client with the actual content type of the returned content.
The HTTP Accept-Charset is a request type header. This header is used to indicate what character set are acceptable for the response from the server. The accept-charset header specifies the character encodings which are accepted by the client and this header also allows a user-agent to specify the charsets it supports.
There is no charset value applicable. PDF is a binary format which handles character encodings internally, in a way that's not relevant to MIME types at all.
You should be sending:
Content-Type: application/pdf
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With