On 4/17/2014 7:50 AM, Christopher Schultz wrote:
I'll take a look at the code to see if maybe we can conditionally log
something somewhere when we get a 400 error. You can probably get
information about it by enabling DEBUG logging on the component that
throws the 400 error, but you'll likely get a huge amount of output in
that log file, which you obviously don't want.
Our first remedial action was to to add URIEncoding="UTF-8" to our HTTP
and HTTPS connectors defined in server.xml, as well as added a character
encoding filter to our webapp's web.xml:
<filter>
<filter-name>SetCharacterEncodingFilter</filter-name>
<filter-class>
org.apache.catalina.filters.SetCharacterEncodingFilter
</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>UTF-8</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>SetCharacterEncodingFilter</filter-name>
<url-pattern>*</url-pattern>
</filter-mapping>
We've not see any issues since. Could this have played a role somehow
in resolving this, or just coincidence for now?
Do you know if using the above setup we can remove our own "JSP page
bean" init code shown below that sets the character encoding like we
have now? Seems like our code below was trying to accomplish what I
believe the SetCharacterEncodingFilter is now doing for every request
(not just those that reach our JSPs).
try
{
if ( request.getCharacterEncoding() == null )
request.setCharacterEncoding(CHARSET_UTF_8);
response.setCharacterEncoding(CHARSET_UTF_8);
}
catch( UnsupportedEncodingException e )
{
app.warning("PageBean.init() - Failed to set request/response to
UTF-8 encoding.");
}
Our JSPs already specify charset=UTF-8 in the content type and/or HTML
meta tag for Content-Type.
We're keeping our fingers crossed!
It could also be possible that a browser is incorrectly-formatting
something. Do you make extensive use of cookies> Do you ever store
anything in a cookie name or value that isn't in US-ASCII? If so, you
might have some edge cases where the overwhelming majority of your
users are find but some folks with Greek names or whatever step-over
into non-US-ASCII and hit some edge cases with either the browser or
Tomcat itself.
Aside from the session cookie for JSESSIONID done by Tomcat, we
generally only have one cookie that is optional for those who want to
save their login email address. For these, we are using
java.net.URLDecoder.decode/java.net.URLEncoder.encode of the email
address string specifying the UTF-8 charset param to the encoder/decoder.
Does that sound like it could be an issue for these edge cases you are
talking about since my impression is that such encoding would ensure
US-ASCII was the cookie value?
Thanks for your help and consideration, Christopher!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
