| Re: [jaxrs-dev] Character set negotiation |
Accept-Charset only applies to text/* mime types, see https://tools.ietf.org/html/rfc7231#section-5.3.3:The "Accept-Charset" header field can be sent by a user agent to indicate what charsets are acceptable in textual response content.
application/json is, from the point of view of the HTTP protocol, not textual content, since it doesn't have a top level type of text. In fact, that's exactly why the JSON spec creators chose application/json, and not text/json, because they wanted JSON encoding to be consistent regardless of what wire protocol it was sent over (https://tools.ietf.org/html/rfc7159#section-8.1 requires JSON to be encoded either as UTF-8, UTF-16 or UTF-32, so if Wildfly is encoding in ISO-8859-1, then it's not conforming to the JSON spec). The JSON spec also makes it explicit that the charset parameter on the content type is not supported and should be ignored.So, conforming servers should be ignoring Accept-Charset when sending application/json content, and conforming servers also should not set the charset in the content type. They should all be using either UTF-8, UTF-16 or UTF-32, otherwise they are not spec conforming, and if they wish to be inter operable, then they really only should be using UTF-8, as suggested by the spec. They should not allow the user to select anything other than UTF-8, UTF-16 or UTF-32, as that would not be valid JSON, according to the spec.On Fri, 22 Feb 2019 at 00:10, Charly Ghislain <charlyghislain@xxxxxxxxx> wrote:_______________________________________________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
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev
--_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jaxrs-dev