https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #20 from c.bollme...@lecare.com --- Hello, just to mention this subtle change did cost us 2.5 team days & a whole lot of stress searching for the needle in the haystack as our app suddenly didn't work anymore with multipart uploads. Or to be precise, *some* multipart uploads did still, others failed, and Tomcat 10.1 rsp. 11.0.8 do behave differently in this case: 11 throws an Exception that for some reason does not get logged most of the time, while 10.1 seems to accept the request but limits it in some way, leading to Spring Security CSRF errors, pointing the bug hunt in a completely wrong direction. And the issue did hit us in production, as our hoster had automatically updated the Tomcat container to the latest version because of, well, security guidelines. In fact, this caused significant downtime and a rollback and SLA violations and in effect, just what the change tried to avoid. We are deeply glad and thankful for the Tomcat Server and the ASF team's outstanding efforts during the last ~25 years, but maybe some suggestions are ok to further enhance the experience ;) 1. A BREAKING change like this (and suddenly reducing the acceptable limits by a factor of 100 (!) definitely is one) should be highlighted in BOLD RED wherever possible and not just mentioned as a Coyote enhancement introducing 2 additional parameters that seemed optional. Breaking change means: it breaks real world application like ours, users complain and so on. There was no mentioning of the new *10* limit in the changelog or that the *magical* boundary was crossed upon the 11th parameter, which is dependant on checkbox states and such in effect. The cause was really really hard to find, and I say this with nearly 30 years under my belt. 2. The *first* thing a developer does in case of a sudden incompatibility is installing a (clean room) new server and checking if the issue is related to the customer environment somewhere or not. At this stage, it's already level 3 support. It would have been *tremendously* helpful if the default config in server.xml would contain an entry for the "max parts count" as there is for e.g.maxParameterCount="1000". As it was, there was *nothing* hinting at a new limit. In fact, we were chasing ghosts. 3. While it is absolutely OK to provide means to limit resource usage as it was implemented, I would still raise the issue of *automatically enforcing* them, even more so, in a *minor* version where nobody expects surch a change (semver rules). I see the issue of providing a 'secure by default' configuration here, but breaking production deployments that may have relied on the previous behaviour since the advent of Servlet API 3.1 or so is a thing to consider, too. I would have preferred to announce the change and make it opt-in. It's not so that Tomcat servers suddenly went down in flames amass, and they haven't in decades. Furthermore, Tomcat usually runs behind an array of other infrastructure, reverse proxies, WAFs and such, in enterprise scenarios at least, which also impose limits similar to the one in question. I'll leave it to three here, thank you for hard work & providing the only remaining JEE server we love to use after 25 years ;) -- Ch. NB. Oh, and ofc the value for maxPartCount should be either set to *42* or *451* for obvious reasons. Jokes aside, in real word applications we see big big wtf_incomprehensible JSP pages and such stuff galore, and you're happy if you don't. From a developer perspective, adding another edit field or checkbox option to a wieldy dialog you hate anyway possibly shouldn't cause the app to break in a most mysterious way ;) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
