Can charset parameter be used with application/json content type in http/1.1?
character-encoding, http, json
Solution
The recent json rfc 7159 says:
Note: No "charset" parameter is defined for this registration. Adding one really has no effect on compliant recipients.
i.e., `charset` must be ignored by compliant recipients.
It is consistent with rfc 2045: "MIME implementations must ignore any parameters whose names they do not recognize." because rfc 7159 still specifies: "Required parameters: n/a; Optional parameters: n/a" for application/json mime media type (no parameters).
The json text is no longer constrained to be an object or an array and the old section 3 that computes the character encoding based on the first two characters is gone in the new rfc. UTF-8, UTF-16, or UTF-32 are allowed but there is no way to specify the encoding (no BOM, UTF-8 is the default).
Can charset parameter be used with application/json content type in http/1.1?
There is no harm if `charset="utf-8"` is used -- utf-8 is the default encoding for json text but other values might be misleading because the value must be ignored by compliant recipients. It can only break clients that parse Content-Type header incorrectly e.g., by comparing it verbatim with "application/json" or clients that attempt to use some other than utf-8 encoding to decode the json text.
May rfc-compliant software generate content type application/json with a charset parameter?
no. No parameters are defined for application/json.
Should rfc-compliant software accept such requests?
yes, it should. The value of `charset` must be ignored.
ECMA-404 (The JSON Data Interchange Format) defines json text in terms of Unicode code points i.e., json itself specifies no behavior regarding encoding details.
ECMA-262 (ECMAScript Language Specification) also defines the json format on top of String (Unicode type).
Problem
For example, is it valid ajax request: ``` $.ajax({ type: "POST", url: "SomePage.aspx/GetSomeObjects", contentType: "application/json; charset=utf-8", ... }); ``` It is used as an example sometimes, or software can break without explicit charset. The rfc 4627 for application/json media type says that it doesn't accept any parameters in section 6: ``` The MIME media type for JSON text is application/json. Type name: application Subtype name: json Required parameters: n/a Optional parameters: n/a ``` It can be interpreted that charset shouldn't be used with application/json. And section 3 suggests that it is not necessary to specify charset: ``` JSON text SHALL be encoded in Unicode. The default encoding is UTF-8. Since the first two characters of a JSON text will always be ASCII characters [RFC0020], it is possible to determine whether an octet stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking at the pattern of nulls in the first four octets. 00 00 00 xx UTF-32BE 00 xx 00 xx UTF-16BE xx 00 00 00 UTF-32LE xx 00 xx 00 UTF-16LE xx xx xx xx UTF-8 ``` because UTF-8,16,32 encodings can be infered from the content. Why does it say that UTF-8 is default? The way to choose other character encoding is not specified in the rfc and the encoding can be found deterministically anyway. Or are there other (not UTF-8,16,32) character encodings that support Unicode? Some argue that charset can be used: I disagree with your assessment that it must be dropped. RFC 2046 states that "other media types than subtypes of "text" might choose to employ the charset parameter as defined here," which indicates that there is no restriction on the presence of the charset parameter on application types. Additionally, RFC 2045 states that "MIME implementations must ignore any parameters whose names they do not recognize." So, it is not reasonable to assume that there is any harm being done by its presence. May rfc-compliant software generate content type application/json with a charset parameter? Should rfc-compliant software accept such requests?