Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
0.18, 0.22, 0.32
-
None
Description
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 '?'.
final Writer writer = getOutputWriter(request,response); ObjectMapper mapper = new ObjectMapper(); mapper.configure(SerializationConfig.Feature.INDENT_OUTPUT, true); mapper.writeValue(writer, object);
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.