On 01/07/2024 07:17, Michael Osipov wrote:
On 2024/06/27 17:13:56 Christopher Schultz wrote:
Michael,
On 6/27/24 08:46, Michael Osipov wrote:
On 2023/03/09 14:23:33 Christopher Schultz wrote:
A potential use-case for "large numbers of parameters" might be an
application that uses something like a multi-select list and the number
of choices is stupendously high. As in, when the application was
designed, the designers said "we can use a multi-select list for this
postal-code selector" and then 5-10 years later, someone said "hey let's
dump all postal codes in the entire US into this multi-select" and there
you have thousands of possibilities which the browser will happily
package-off to the server.
FTR, guess what? We have been hit by this.
Nostradamus.
Spot on.
We have an HTML form for the user where he sees a diff between a src
and dest. Technical values, can be thousands. The selected value ids
are POSTed. Users have been complaining that they miss data. I took
me some time to remember (actually weeks between report and memory)
that I have replicated maxParameterCount="1000" to our server.xml
without using FailedRequestFilter. Retrospectively, it should have
gone hand in hand with that filter and not without. Rather fail fast
than suffer data truncation.
I don't think there is really a way for us to push a <Filter> into all
web applications.
I mean... there MAY be a way to do it, but it will likely be ugly and we
would also have to "move" it if the application defines filters in a
specific order including the FailedRequestFilter.
The good news is it doesn't do anything weird like trigger
request-parsing or try to do anything with character sets or whatever.
The real question is whether or not this kind of thing should be handled
in a Filter or just handled by Tomcat itself. Why bother waiting for the
application to check: just throw an exception and kill the request
processing.
I have spent the whole Friday to provide data to engineeing that has been
truncated. It seems that we have upto 3000 form values submitted. I have bumbed
to 5000 now.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
