On 2024/07/02 11:06:55 Rémy Maucherat wrote: > 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.
I won't oppose, August release would be just fine. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
