[
https://issues.apache.org/jira/browse/MESOS-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270610#comment-15270610
]
Whitney Sorenson commented on MESOS-2013:
-----------------------------------------
Sometimes prioritization feels like the hardest problem in software. At least
this issue is clearly a bug, is clearly reproducible and has clear impact for
those of us using the slave to read files. I suppose one alternative we will
need to consider is whether to build and deploy our own separate proxy for
reading files from mesos slaves.
I will say we have been using mesos since version .12 and this is the one of
the most onerous issues we've had (excepting troubleshooting the network
handshake between master and framework - but HTTP API will solve that once and
for all.)
> Slave read endpoint doesn't encode non-ascii characters correctly
> -----------------------------------------------------------------
>
> Key: MESOS-2013
> URL: https://issues.apache.org/jira/browse/MESOS-2013
> Project: Mesos
> Issue Type: Bug
> Components: json api
> Reporter: Whitney Sorenson
> Assignee: Anand Mazumdar
>
> Create a file in a sandbox with a non-ascii character, like this one:
> http://www.fileformat.info/info/unicode/char/2018/index.htm
> Hit the read endpoint for that file.
> The response will have something like:
> data: "\u00E2\u0080\u0098"
> It should actually be:
> data: "\u2018"
> If you put either into JSON.parse() in the browser you will see the first
> does not render correctly but the second does.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
