Can charset parameter be used with application/json content type in http/1.1?

application/json doesn't define a charset parameter, so it is incorrect to include one. What RFC 2046 says is that application types in general could have a charset parameter, such as application/xml. But JSON does not.

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).

Should rfc-compliant software accept such requests?

According to Julian Reschke's answer, apparently not. However, as you pointed out, you will potentially encounter it in the wild and then would have to cope with it, if you want to talk to those non-rfc compliant hosts.

For one, if you have code in place that handles Accept-Charset and the charset part of content types for text-based messages in your HTTP framework, why not just use it for JSON, too? Programming-wise, it is both easier (no special rule for json) and more general.

Personally, I'd say let's go Unicode (using the encoding detection you quote) for every bit of text. Unfortunately, there are client devices out there, e.g. Japanese mobile phones, that don't handle Unicode, but only Shift_JIS. They'd otherwise be happy JSON consumers (and paying customers). So what are you going to do? In my particular case, to get these clients on board, I made the charset configurable via the standard HTTP mechanisms.

On a side note, HTTP 2.0 is being worked on right now, and if the guys ever hope to create a standard that is rigidly adhered to, they will have to write acceptance tests. That could of course also mean excluding aforementioned legacy clients if the rules can't be bent occasionally.

And what's the point of being compliant if nobody else is but you? I wonder if even Opera is compliant, or, for that matter, if all the RFCs it implements can be unambiguously interpreted in the first place. I don't think so, especially in the case of larger ones like HTTP.

If this sounds like HTTP bashing, let me just say this: HTTP is a great standard with concepts that revolutionized not only the internet. The way e.g. resources are specified (statelessness), or the way caching is done, has established good patterns that have trickled down into the implementations of many applications. And HTTP 2 could pick up where 1.1 left off. Let's just hope that SPDY won't be adopted 1 to 1. I hate to say it, but in this case it looks like Microsoft's HTTP Speed+Mobility is in many ways more HTTP-ey than Google's PUSHy (and insofar unRESTy) SPDY.