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.
Regards,
Endre.
Which is why the following text appears in the docs for this valve:
<doc-quote>
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.
</doc-quote>
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
