<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/19/16 8:55 PM, Mark Juszczec
wrote:<br>
</div>
<blockquote
cite="mid:CAMC-JMUcbKvgK7s8hUoTv10JAC7MNhhXtFiY=X+9NLbXjzKH1A@mail.gmail.com"
type="cite"><br>
<p dir="ltr">Tomcat is configured to use AJP 1.3 for
communication.</p>
<p dir="ltr">The problem is the UTF-8 data is corrupted once it
comes off the AJP port. </p>
<p dir="ltr">I have debugged into the Tomcat AJP classes and see
the bytes are correct. They arrive in an object called
ByteChunk and are then converted to a String and the charset is
ISO-8859-1.</p>
<p dir="ltr">The String is incorrect.</p>
<p dir="ltr">ISO-8859-1 is the default used by ByteChunk and I've
verified it is not reset/changed to UTF-8 despite having
specified it in server.xml per Tomcat documentation.</p>
<br>
</blockquote>
<br>
I don't think I've fully groked all the details in this thread, but
wanted to share 2 things which I haven't seen yet which might be
relevant:<br>
<br>
1) In the servlet spec (section 3.11) it does say:<br>
<br>
<blockquote type="cite">The default encoding of a request the
container uses to create the<br>
request reader and parse POST data must be “ISO-8859-1” if none
has been specified<br>
by the client request.</blockquote>
<br>
which means mainly the charset on an entity body Content-Type type.
But read on..<br>
<br>
<br>
2) Since many requests don't include a request character encoding,
and lots of things want it to be UTF-8, Tomcat comes with servlet
filter which looks at the HttpServletRequest's characterEncoding
property, and if null, sets it explicitly to UTF-8 (by default,
actually you can configure any encoding you want). This is again
mainly about processing POSTed data, according to the comments, but
since the request encoding is always set/available, it might have
some relevance to this issue. You can find this filter in the
global conf/web.xml as "setCharacterEncodingFilter". It's commented
out by default.<br>
<br>
As someone else pointed out, there are some params on the AJP
connector, but those appear to be about the URI query params only.
The servlet filter approach might work for this case, since it
globally sets the whole request encoding.<br>
<br>
(Backstory: I recently had an issue with non-ISO-8859-1 characters
in POST params on an signed LTI launch request. The interpretation
of them as ISO-8859-1 in the Java app was causing the signature to
be broken. The servlet filter solution seemed to fix. Really IMHO
the signer needs to put the charset in the posted Content-Type, but
that's another matter...)<br>
</body>
</html>