tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <>
Subject Re: RequestDumperValve screws UTF-8 parameter parsing
Date Mon, 09 Jan 2006 22:54:38 GMT
I've produced my own servlet filter to get around this -- which does not 
dump request parameters until *after* the request has completed.

With almost no additional effort you can then add request elapsed time, 
etc, etc, to this.

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.
>Which is why the following text appears in the docs for this valve:
>WARNING: Using this valve has side-effects. The output from this valve
>includes any parameters included with the request. The parameters will
>be decoded using the default platform encoding. Any subsequent calls
>to request.setCharacterEncoding() within the web application will have
>no effect.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message