On Tue, Jul 2, 2024 at 1:05 PM Mark Thomas <ma...@apache.org> wrote: > > 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.
It seems UserDataHelper needs some changes then, careful about last minute breakage. Rémy > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
