You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2015/06/15 09:52:00 UTC
[jira] [Comment Edited] (QPID-6588) HTTP Management writes JSON
responses using the platform's default encoding rather than UTF-8
[ https://issues.apache.org/jira/browse/QPID-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585548#comment-14585548 ]
Keith Wall edited comment on QPID-6588 at 6/15/15 7:51 AM:
-----------------------------------------------------------
>From what I have read, setting the character encoding is superfluous. Content type "application/json" requires that an encoding of unicode (UTF-8, UTF-16 or UTF-32) is used and the nature of a valid JSON response means that the recipient is able to distinguish which unicode encoding with no ambiguity. Jackson defaults to UTF-8. If we are to send the content-encoding header, we should send the value from Jackson, just in case they ever change it to use a different one.
The code that is responsible for setting headers is a mess with lots of duplication.
was (Author: k-wall):
>From what I have read, setting the character encoding is superfluous. Content type "application/json" requires that an encoding of unicode (UTF-8, UTF-16 or UTF-32) is used and the nature of a valid JSON response means that the recipient is able to distinguish which unicode encoding with no ambiguity. Jackson defaults to UTF-8. If we are to send the content-encoding header, we should send the value from Jackson, just in case they ever change it to use a different one.
The code that is responsible for setting headers is a mess with lots of duplication.
> HTTP Management writes JSON responses using the platform's default encoding rather than UTF-8
> ---------------------------------------------------------------------------------------------
>
> Key: QPID-6588
> URL: https://issues.apache.org/jira/browse/QPID-6588
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: 0.18, 0.22, 0.32
> Reporter: Keith Wall
>
> The HTTP Management implementation writes JSON responses using the platform's default encoding rather than an encoding Uncode meaning characters outside ASCII may be lost. It also breaks RFC7159, which states that "JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8")
> The issue is that the implementation (MessageServlet, RestServlet) passes a Writer to the Jackson ObjectMapper and that Writer is an OutputStreamWriter that use the platform's default character encoding. This effect of this is that any character that cannot be represented using the platform's default encoding will be converted to a '?'.
> {code:java}
> final Writer writer = getOutputWriter(request,response);
> ObjectMapper mapper = new ObjectMapper();
> mapper.configure(SerializationConfig.Feature.INDENT_OUTPUT, true);
> mapper.writeValue(writer, object);
> {code}
> The solution is to configure the OutputStreamWriter with a UTF-8 character encoding, or more simple pass the output stream to the Jackson mapper directly.
> [1] https://tools.ietf.org/html/rfc7159
> This problem was exposed by the new tested added to MessagesRestTest QPID-6545. The test would pass (for the wrong reasons under Intellij), then fail on the command line (persumably owing to platform encoding default differences).
> This problem will affect a user trying to view message content where the message contains strings that contain characters falling outside ASCII. It may also affect users trying to manage objects (exchanges/queues etc) whose names fall outside ASCII. The user can workaround by using JMX management channel.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org