tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre Stølsvik <En...@Stolsvik.com>
Subject Re: RequestDumperValve screws UTF-8 parameter parsing
Date Tue, 10 Jan 2006 09:02:22 GMT
On Mon, 9 Jan 2006, Mark Thomas wrote:

| Endre Stølsvik wrote:
| > Enabling the RequestDumperValve in both 5.5.12 and 5.0.16 (!) messes up
| > the parsing of other-than-ISO-8859-1 incoming parameters.
| > 
| > After using a rather huge bunch of hours, this came down as the result:
| > when this "debug valve" is turned on, it seems to default to ISO-8859-1
| > when it parses and log-outputs the incoming parameters, thus also
| > implicitly setting the entire Request-object to this enc, so any
| > subsequnt setting to UTF-8 doesn't matter at all. At least this is true
| > for POST paramters.
| > 
| > For GET parameters, the situation is a little different. Here an
| > explicit setting of URIEncoding to UTF-8 seems to work as it should,
| > while useBodyEncodingForURI doesn't - it picks up the wrong already
| > implicitly set encoding. (For 5.0.16 I can't seem to get the latter
| > version to work, and have to use the explicit setting.)
| > 
| > Sorry if my analysis doesn't hold water, but at least the bug seems to
| > be very consistent.
| > 
| > Regards,
| > Endre.
| 
| Which is why the following text appears in the docs for this valve:

When was this added? See, I have a hunch that this comment wasn't there in 
the beginning.

Why isn't this slightly important point put in a clearly visible place 
within the server.xml file then?! Or the code just fixed, or rather just 
deleted off of the face of the earth until some code who haven't got his 
head totally up a ASCII-speaking place makes a usable version of it?

Tomcat 5.5.12's server.xml:

      <!-- The request dumper valve dumps useful debugging information about
           the request headers and cookies that were received, and the response
           headers and cookies that were sent, for all requests received by
           this instance of Tomcat.  If you care only about requests to a
           particular virtual host, or a particular application, nest this
           element inside the corresponding <Host> or <Context> entry instead.

           For a similar mechanism that is portable to all Servlet 2.4
           containers, check out the "RequestDumperFilter" Filter in the
           example application (the source for this filter may be found in
           "$CATALINA_HOME/webapps/examples/WEB-INF/classes/filters").

           Request dumping is disabled by default.  Uncomment the following
           element to enable it. -->
      <!--
      <Valve className="org.apache.catalina.valves.RequestDumperValve"/>
      -->

Putting some high risk debugging feature within the default example 
server.xml file as "yeah, this is fucking cool, just uncomment this to 
debug your problems" without in the same breath pointing out that this 
will increase the exact problems you're trying to fix, is rather 
provocative after using 7 hours of debugging time on a I18N problem where 
my bleedin' parameters including something as simple as my three extra 
scandinavian characters "æøå" won't get through correctly.

Really, how can a "request dumper feature" that cannot handle any other 
charsets than the default Locale's the user running the JVM has, still be 
present in the default example config of the powerful and one-would-assume 
better-than-this Tomcat??

Anyways, thanks for answering, Thomas. If you have commit access (or any 
other reading this), then maybe you'd care to shove in a line at the top 
of the quoted comment, AND the bottom within the comment-out part of the 
definition, along the lines of:

"EXTREME WARNING / ERROR: Enabling this will most definately mess up all 
your parameter handling unless you live in USofA or England (and won't 
test for I18N anyways), or if mercury's third moon happens to be aligned 
with mars."

(and/or simply delete the damn class)

.. then maybe the next poor bastard hitting some I18N problems won't get 
caught using a debugging feature that will _ensure_ that his problems 
won't _ever_ go away.

Kind regards,
Endre.

Mime
View raw message