Re: [BUG] Parameters.recycle() does not reset queryStringCharset — leaks across recycled Requests

Mark Thomas <[email protected]> Fri, 29 May 2026 13:19:47 +0100
Newsgroups gmane.comp.jakarta.tomcat.user
Message-ID <[email protected]>
On 29/05/2026 04:53, 황인엽 wrote:
> # Parameters.recycle() does not reset queryStringCharset,

Agreed.

> causing cross-request charset leakage

Not so sure about that.

> The author's mental model is "if I don't call `setQueryStringCharset`,
> Tomcat uses its default (UTF-8) for this request."

Even if queryStringCharset was recycled, that model isn't quite correct. 
The default is Connector.getURICharset() (which might not be UTF-8).

Which goes some way to explaining why Tomcat behaves the way it does. 
Any why the suggested fix is not correct.

The character set Tomcat is going to use to decode the URI needs to be 
declared before Tomcat starts parsing the URI. Therefore, it cannot be 
part of the request. It also follows that the administrator has to pick 
a URI encoding and - effectively - stick to it.

The query string is part of the URI but there is a little more 
flexibility as the contents of the query string can be processed much 
later than the rest of the URI. Tomcat supports per request query string 
encoding via Connector.getUseBodyEncodingForURI(). If this is set, 
parameters.setQueryStringCharset() is called on every request.

Because of all of the above, there is no need for Tomcat to reset the 
queryStringCharset between requests.

The other part of this is that the Parameters object does not have 
visibility of Connector.getURICharset() which complicates resetting it.


Once custom Valves start poking around in the Tomcat internals, it 
becomes the responsibility of those Valves to understand the internals 
they are poking around in and act accordingly.


Tomcat can reset this every request - just not in the recycle() method 
which will need some comments to explain what is going on.

I did think about possible regressions but I can't think of any 
realistic scenarios where resetting per request would cause a problem as 
long as the reset happens right at the start of the request and 
especially before the Valve pipeline.

I'm working on this now and hope to have a solution for the June releases.

Mark