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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
