On 2024/07/02 10:33:29 Mark Thomas wrote: > 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.
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. Michael --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
