Describe the bug

When computing a content-type header, RESTEasy Reactive shouldn't forcefully append a charset attribute to all text based media-types, including application/json.

It was not originally the case, this change was introduced by this commit: 60aa2b7

As per the IANA spec for application/json:

Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.

This can be interpreted in several ways I guess. I interpret it as:

• Adding a charset attribute is incorrect
• Recipients are expected to be lenient but that doesn't make it any less incorrect

The reason behind this is that JSON requires either UTF-8, UTF-16 or UTF-32 encoding and parsers are expected to detect the correct encoding based on the first bytes.

Expected behavior

content-type: application/json

Actual behavior

content-type: application/json;charset=UTF-8

How to Reproduce?

https://github.com/quarkusio/quarkus/blob/3.15.1/independent-projects/resteasy-reactive/server/vertx/src/test/java/org/jboss/resteasy/reactive/server/vertx/test/mediatype/CharsetTest.java#L56

Output of uname -a or ver

irrelevant

Output of java -version

irrelevant

Quarkus version or git rev

3.15.1

Build tool (ie. output of mvnw --version or gradlew --version)

irrelevant

Additional information

Note: this broke our Keycloak client when we upgraded because it was strict. We fix it and made it lenient but I still think this is also a server side issue and charset shouldn't be there.