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. Michael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
