Dear all,
I would like to raise a minor issue I think is due to non-explicit specification.
Considering a REST endpoint with this signature:
@Produces(MediaType.APPLICATION_JSON)
public MyPojo getMyPojo();
There seem to be no explicit way for the server to choose a charset to encode the json response.
I tested both payara (jersey) and wildfly (resteasy). An 'accept-charset' header sent by the client seems to be ignored by both servers, each returning a response encoded with their default value, apparently utf-8 for payara and iso-8859-1 for wildfly. None of them mention it in the content-type response header.
If the client requests the character set in the 'accept' header, then payara will append it in the 'content-type' response header, but still encode it in utf-8. Wildfly ignores it as well, but does not append anything in the 'content-type' header.
The spec mention that an 'accept-charset' header is supported by the runtime if the application calls 'selectVariant' on the request, and pass the returned variant mediatype to the response builder. This implies the application developer has to enumerate the supported character sets.
Given than java supports encoding strings for a large range of character sets, shouldn't the runtime be able to honor the charset requested by the client, and mention it in the response, without any action required for the application developer?
Enforcing it would still be possible for an application developer.
Thanks for your comment,
Charly
