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?