On 02/07/2024 12:01, Michael Osipov wrote:
On 2024/07/02 10:33:29 Mark Thomas wrote:
On 01/07/2024 07:17, Michael Osipov wrote:
<snip/>
I would really really expect that Tomcat fails hard with 4xx if the input is
invalid and not issue a simple INFO at the log. The huge problem is that the
request is seen as 2xx or 3xx in the access log and if you have a lot of
requests or forms it will be needle in the haystack to identify which is really
the problem.
Even worse, if this has not been written by you you can play ping pong with the
software vendor.
Therefore, I'd like all of us (committers) to reconsider this soft non-failing
approach. It is not helpful. If the client provides garbage it should fail
immediately.
With Tomcat 11.0.x you will get a hard fail.
Prior to Tomcat 11 our hands are somewhat tied by the Servlet
specification since getParameter() and friends are documented to not
throw an exception.
We can't change the default behaviour for Tomcat versions before 11 as
that runs the risk of breaking existing applications that have been
designed for the current behaviour.
All we can do is make that hard failure optional and it already is. For
a (very) long time we have had the FailedRequestFilter for folks that
wanted a hard failure if there was an issue with parameter parsing.
Changing the default for maxParameterCount from 10,000 to 1,000 doesn't
change this.
The documentation for maxParameterCount already documents all of this.
I don't see a need for any changes here.
Thanks, I see. As a comprise would a move to WARN log message be accepted? This
will at least draw people's attention. INFORMATION is just lost with other
output.
That seems reasonable to me.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
