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.
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.
It could be a well-documented Exception class that any application could
configure in an <error-page> configuration and they can intercept it.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
