Is it categorically wrong to send a charset parameter with a Content-Type header for non-text media types?

3
votes

I've tracked down a bug between two pieces of software, one of them is emitting the header

Content-Type: application/x-bittorrent; charset=utf-8

And the other is handling this incorrectly, but handles it correctly if the charset parameter is dropped. I need to know which software to write a patch for!

According to the W3C's website:

Documents transmitted with HTTP that are of type text, such as text/html, text/plain, etc., can send a charset parameter in the HTTP header to specify the character encoding of the document.

Which implies that documents not of type text should not send this header, I think. However, RFC 2068 states:

The "charset" parameter is used with some media types to define the character set (section 3.4) of the data

I cannot find anywhere in the spec that it is incorrect to add a charset parameter to media types other than text, so my question is: Is the software emitting this header incorrect, or the software consuming it?

2
httphttp-headerscontent-type
I've found a second piece of software that handles it "incorrectly" on the consumption side, so I'm leaning towards it being incorrect to include charset for types other than text. The W3C language could intend this, especially if you read it as the exception that proves the rule. I'm not certain though. – ZoFreX

2 Answers

3
votes

(1) The relevant spec if RFC 2616, not 2068.

(2) The HTTP spec is correct, it depends on the media type. For instance, you can send a charset parameter for application/xml.

(3) Dunno about application/x-bittorrent - does it have a spec?

-1
votes

I think it is incorrect to add a charset parameter for anything other than a text/* media-type, as the spec only permits adding charset for that.