You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2025/06/11 10:24:36 UTC
[Bug 69710] New: FileCountLimitExceededException is thrown in version 11.0.8
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Bug ID: 69710
Summary: FileCountLimitExceededException is thrown in version
11.0.8
Product: Tomcat 11
Version: unspecified
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: aleksandr.beliakov@nowina.lu
Target Milestone: -------
Hello,
After upgrading to Tomcat 11.0.8, we experience an issue with one of our
website forms, as on submit Tomcat throws
org.apache.tomcat.util.http.fileupload.impl.FileCountLimitExceededException
exception:
Caused by:
org.apache.tomcat.util.http.fileupload.impl.FileCountLimitExceededException:
attachment
at
org.apache.tomcat.util.http.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:459)
at org.apache.catalina.connector.Request.parseParts(Request.java:2551)
The issue seems to be introduced within the commit
https://github.com/apache/tomcat/commit/e34fe96ef8ee782b0e56b64358e8dc57cbe336a6,
which sets upload.fileCountMax parameter to the value of a new introduced
maxPartCount parameter, which is set to 10 by default.
Before, the value of maxParameterCount was used, which was set to 1000.
We do not think the reduction of 100 times is appropriate in this use case, as
the value of "10" limits very common scenarious. We would prefer to have the
value increased to at least "100".
The problem for us is also that we do not use an embedded tomcat and we deliver
only a spring-boot WAR file, thus it is impossible for us to configure the
behavior on our side.
Therefore, could you please increase the default value for the constraint to
100?
Same issue is present in Tomcat 10.1.42.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
clement.demoulins@faveod.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |clement.demoulins@faveod.co
| |m
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|REOPENED |RESOLVED
--- Comment #30 from Mark Thomas <ma...@apache.org> ---
Rémy has added debug logging if the limits are reached.
With that, I do think there is anything else to be done for this issue.
Updated limits and logging will be in the July releases.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #8 from Aleksandr Beliakov <al...@nowina.lu> ---
Thank you for the clarification.
Considering the parameters include both file and non-file fields, I am even
more concerned about the choice that have been made to set the total number of
parameters to 10. What was the rational for choosing this as the value? I am
pretty sure the default value is too small and this change is going to impact
many systems, once they upgrade to the new Tomcat version.
To our opinion, this is not a change that should be present in a minor version
upgrade, as it is going to impact many current solutions and will require
developers to adjust their systems.
Therefore, I would still insist on increasing the default value to 100. Thank
you for understanding.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #19 from Rainer Jung <ra...@kippdata.de> ---
I didn't inspect the code, but would it be possible to roughly count the bytes
while reading/processing the request and err out if it gets too large? That way
we could increase the limits of the factors in the formula without risking the
product to get to big.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #20 from c.bollmeyer@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #26 from Mark Thomas <ma...@apache.org> ---
Tomcat has a sufficiently wide range of users and uses that I suspect that
introducing lower limits for additional parameters would trigger further issues
along similar lines to this one regarding the changes to those limits.
Increasing the default maxPartCount to 50 along with documentation updates
still looks to be the best way forward.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #4 from Aleksandr Beliakov <al...@nowina.lu> ---
The problem for us is that the code fails even when I submit a single file. But
because I have some other input fields, it throws an exception
FileCountLimitExceededException. Which is very confusing. We do not think the
behavior is expected.
For the context, we have a form with more than 10 fields, but with most of them
being only check or radio boxes. Only some of them are file fields, and all of
them except one are optional.
We provide an open-source application delivered in a WAR file, with no
possibility to configure the Connector in an external Tomcat. Therefore it is
impossible to increase the limits on our side. This will unfortunately impact
our users that will need to figure out the problem on their own (which is also
not self-explanatory with the current exception).
We believe this limitation will impact other Tomcat users soon, therefore we
respectively ask to increase the default limits or modify the behavior, if
possible.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #21 from Remy Maucherat <re...@apache.org> ---
We're really sorry for the trouble, but that's basically how CVEs work these
days. They have to be secured by default regardless of the immediate
consequences. There are plenty of examples out there of very disruptive
security exploits, or fixes to these exploits.
Really bad luck if you're hovering between 10 and 11 parts, this indeed makes
the issue harder to understand.
Once everyone is aware of this (and we will likely adjust the default for
maxPartCount up slightly, although it will remain way way below the previous
1000), it becomes just another parameter to set in the configuration.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #33 from Christopher Schultz <ch...@christopherschultz.net> ---
Honestly, maxPartHeaderCount and maxPartHeaderSize are essentially the same
thing. If you are allowed to have 2kb of headers, then you can only have a
certain maximum number of headers as well. You can't have infinite part-headers
fit inside of 2kb.
I'm not entirely sure of the history of maxHeaderCount vs maxHeaderSize, but
the maxHeaderSize has much more to do with consistent buffer sizing within the
container and is much more important than limiting the actual number of
headers.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #16 from Carlos Cerrillo <cc...@gmail.com> ---
I believe that any value between 30 and 60
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Aleksandr Beliakov <al...@nowina.lu> changed:
What |Removed |Added
----------------------------------------------------------------------------
OS| |All
--- Comment #1 from Aleksandr Beliakov <al...@nowina.lu> ---
Alternatively, a special parameter maxFileCount could be used in order to set
the value explicitly (with 100 by default).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #3 from Aleksandr Beliakov <al...@nowina.lu> ---
The problem for us is that the code fails even when I submit a single file. But
because I have some other input fields, it throws an exception
FileCountLimitExceededException. Which is very confusing. We do not think the
behavior is expected.
For the context, we have a form with more than 10 fields, but with most of them
being only check or radio boxes. Only some of them are file fields, and all of
them except one are optional.
We provide an open-source application delivered in a WAR file, with no
possibility to configure the Connector in an external Tomcat. Therefore it is
impossible to increase the limits on our side. This will unfortunately impact
our users that will need to figure out the problem on their own (which is also
not self-explanatory with the current exception).
We believe this limitation will impact other Tomcat users soon, therefore we
respectively ask to increase the default limits or modify the behavior, if
possible.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #5 from Remy Maucherat <re...@apache.org> ---
Ok, so what would be a reasonable default value in your opinion ?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #6 from Aleksandr Beliakov <al...@nowina.lu> ---
I did some tests, it seems like Tomcat mixes a number of fields and number of
files uploaded. On some of the forms, I have a limit of 5-10 files per form, on
others I cannot submit even a single file...
I would say either the code should validate the number of files more
explicitly, separating files number and fields number validation, or as a
temporary solution, increase the current value of maxPartCount parameter to
100.
We have some real-life scenarios with validation of documents from public
administrations, when a set of more than 30 files shall be provided. Therefore,
even a limit of 10 files is too small.
We propose to set the max file count (or maxPartCount) to 100. It still
decreases the previous value of 1000 (delivered from maxParameterCount in
Tomcat v11.0.7), but still big enough to support common scenarios.
Please note that also there exist limitations on a file size and a total size
of files submitted, thus the increase of maxPartCount to 100 won't impact the
security of existing systems.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #24 from Mark Thomas <ma...@apache.org> ---
That is a potential 800MB memory usage on Tomcat 9 + Java 8 and 400MB memory
usage for everyone else.
That seems to be a reasonable default to me. It is higher than I would selected
given a free choice but given the feedback received, it does seem a higher
default is required to better support the forms currently in use with high
numbers of fields. And there is the ParameterLimitValve for more fine-grained
control if required.
As has been suggested, I can provide some of these calculations in the docs so
folks can more easily make their own tradeoffs.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #14 from Carlos Cerrillo <cc...@gmail.com> ---
I agree with option b: increasing maxPartCount to better support real use cases
with many parts
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #13 from Remy Maucherat <re...@apache.org> ---
The previous defaults were there without doing the math (and even more often
new features were added on top of the existing defaults), so when you multiply
everything it gets out of hand.
Obviously mitigations are that multipart is not often out of auth or easily
accessible for scripting and so on.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Fabian Hahn <ef...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P1
CC| |effhaa@gmail.com
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
--- Comment #2 from Mark Thomas <ma...@apache.org> ---
If you want a different default, you can see maxPartCount on the Connector.
If you want per URL control of the limit (and maxParameterCount and
maxPartHeaderSize), you can use the ParameterLimitValve.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #17 from Remy Maucherat <re...@apache.org> ---
30 to 60 just like that seems too high to me, 25 would be 400MB, which is
already huge. You got to realize that processing this is not free if an
attacker shows up with a fully populated request.
One thing I was considering personally is relaxing the default limit
dynamically (maybe up to the proposed 50 or 60) if there is an authenticated
user (userPrincipal != null). This does not cover everything 100%, and is
clearly not out of reach of an attacker in some cases, but this is something
that can reasonably make people's like easier.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #25 from Paolo B. <pi...@tiscali.it> ---
Hello to everybody,
I'm very much in agreement with those who commented before me. I understand the
discussion around CVEs, and I too want to thank everyone for the effort in
maintaining Tomcat, such a long-standing project that I’ve also been using for
many years as my only application server.
I just wanted to add that, perhaps, to mitigate this situation, it might be
better to reformulate all the parameters in a way that achieves the same result
while breaking as few webapps as possible.
Here’s my first consideration: a real workd webapp or rest service cannot
handle 8192 *concurrent* requests with just a few MBs of dedicated memory.
Surely, before hitting the memory limit, there will be issues with CPU,
networking, and I/O depending on the type of application.
A real-world webapp typically does several things, so after processing each
request, various other system resources will be used (DB, filesystem, etc.),
unless you're in a multi-tier environment.
And if a webapp needs to handle 8k "real concurrent requests", it surely has a
development team that will have already customized all the parameters manually.
So, my proposal is as follows:
maxConnections: 1000
maxPartHeaderSize: 1024
maxPartCount: 100
Based on your previous formula, we get:
1k x 100 x 1000 x 2 =~ 200Mb
If you're really sure that 512 byte are enough for multipart request headers
the following value could do the math:
maxConnections: 2500
maxPartHeaderSize: 512
maxPartCount: 100
Based on your previous formula, we get:
0.5k x 100 x 2500 x 2 =~ 250Mb
Bonus tips:
1) explain that this new parameters will limits all multipart parameters and
not only the uploaded files
2) rename the FileCountLimitExceededException to
MultipartParametersExceededException
3) be sure that it will logged by Tomcat (for example JSF hides this exception
at the moment)
Cheers to everyone
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #27 from Remy Maucherat <re...@apache.org> ---
(In reply to Mark Thomas from comment #26)
> Tomcat has a sufficiently wide range of users and uses that I suspect that
> introducing lower limits for additional parameters would trigger further
> issues along similar lines to this one regarding the changes to those limits.
>
> Increasing the default maxPartCount to 50 along with documentation updates
> still looks to be the best way forward.
About item 3), I think I'll add single line (info level ?) logging for
partsParseException and parametersParseException before rethrowing. Although a
framework is not supposed to silently ignore exceptions, I guess it can happen.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #28 from Mark Thomas <ma...@apache.org> ---
I suspect the issue there is that prior to Servlet 6.1 getParameter() and
friends weren't allowed to throw exceptions so there was no way to signal to
the application that parameter (part) parsing had hit a limit.
Servlet 6.1 fixed that by allowing a runtime exception to be thrown. If a
framework swallows that then I class that very much as a framework issue.
A log message would certainly help but historically we have tried to avoid
logging what are essentially request issues as there were concerns about DoS
via filling logs. Maybe do it via a UserDataHelper. A log message (including
stack trace) will be generated but only once per 24 hours by default.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #9 from Remy Maucherat <re...@apache.org> ---
The problem seems that you are not using multipart very efficiently. If you
have trivial flag parameters to pass, then URL params work, for starters.
Although multipart happened to work in all cases, this was an assumption that
maybe was not very reasonable.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #22 from Brice <br...@isp.idaho.gov> ---
I wanted to add my voice to those concerned about this change.
Upgrading to Tomcat 10.1.42 introduced new
org.apache.tomcat.util.http.fileupload.impl.FileCountLimitExceededException
errors in some of our existing applications.
We were surprised. And we were not alone. See
https://stackoverflow.com/questions/79667827/tomcat-multipart-upload-for-many-attachments-10-not-working-after-update-to-9
and
https://stackoverflow.com/questions/79670639/how-to-configure-tomcat-max-file-count-size
I’d echo Hannes Rosenögger and others above suggesting that the Changelog could
have been more helpful in communicating this potentially breaking change in a
way that would have allowed us to resolve the issue more quickly. In our case,
adjusting the Connector’s maxPartCount attribute value to 100 was the quick
workaround. (We have a large dynamic multipart form having only a single file
input. This form starts around 60 request parameters, but may increase based on
how the user interacts with the form having JS insert new form elements into
the DOM.)
Absolutely love Tomcat and have been using it my entire professional career
(since the early 2000s). Thank you Tomcat team for such a great piece of
software!
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #15 from Mark Thomas <ma...@apache.org> ---
Increasing it to what?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #32 from Mark Thomas <ma...@apache.org> ---
Those changes would need to happen in Commons FileUpload.
Changing the meaning of maxPartHeaderSize isn't an option as it would break
backwards compatibility but adding a new option to limit the total header size
is a possibility.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #18 from 123haynes@gmail.com ---
My thoughs on this:
1. Communication of new enforced Limits.
If Tomcat introduces new Limits for whatever reason (CVEs oder other things) it
should be clearly stated that there are new limits to prevent confusion.
No need to justify exactly why in the release notes, but instead of writing:
"Provide finer grained control of multi-part request processing via two new
attributes on the Connector element."
It would be way more helpful for users to read something like:
"Introduce new default limits for multi-part request processing.
maxPartCount=10 and maxPartHeaderSize=512. Please check the documentation here:
[link]"
This is something that can easily be improved regardless of the discussion
about whether the new limits are apropriate or not :)
2. regarding the proposed limits I think option b in combination with option a
would be good default values. so 60 for Java 8 and 120 for everything newer.
It would break way less apps and still be a considerable improvement.
Also imho most servers have more than 1 GB RAM to spare. Especially in
Enterprise contexts :)
But in the end those are just default values.
Maybe very low values are ok even if they break a lot of apps as long as people
are aware of them.
Maybe we could offer some examples like what Mark did here in the comments :)
10kb x ~1k x 8k x 4 = 320Gb
0.5k x 10 x 8k x 4 = 160Mb
Maybe add some values for 1Gb and 500Mb as well.
Imho the most actionable thing is to better communicate the new limits so
people can make an informed decision what's best for their specific use case :)
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #29 from Remy Maucherat <re...@apache.org> ---
(In reply to Mark Thomas from comment #28)
> A log message would certainly help but historically we have tried to avoid
> logging what are essentially request issues as there were concerns about DoS
> via filling logs. Maybe do it via a UserDataHelper. A log message (including
> stack trace) will be generated but only once per 24 hours by default.
That's a nice idea but the log should probably go to context.getLogger() so
UserDataHelper cannot be used here.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #34 from Chen Jp <ch...@msn.com> ---
(In reply to Mark Thomas from comment #32)
> Those changes would need to happen in Commons FileUpload.
>
> Changing the meaning of maxPartHeaderSize isn't an option as it would break
> backwards compatibility but adding a new option to limit the total header
> size is a possibility.
Suggest introduce partHeaderTotalSizeMax and partHeaderTotalCoutMax, apply to
all header information for all parts in a single upload file request.
see commons-fileupload PR https://github.com/apache/commons-fileupload/pull/425
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #7 from Christopher Schultz <ch...@christopherschultz.net> ---
There is no difference between "files" and "non-files" when it comes to
multipart requests. There are only names and values. The fact that your
application treats the differently comes down to application semantics.
So we can't really count files separately from "normal" parameters in a
multipart request.
If you need more than 10 parameters (including both files and non-files), then
you will have to change the configuration to allow that.
If you distribute a WAR file to your customers, you *must* have some kind of
configuration guide for the environment into which it is deployed. Something
like ensuring there is enough heap space, the right resources are available
(e.g. JNDI, JDBC, SMTP), etc.
Your application can inspect the Tomcat configuration on start-up and issue a
warning / error if it doesn't meet your application's requirements.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #31 from Chen Jp <ch...@msn.com> ---
Originally there were several configurable limitation:
1. maxPostSize on Connector (default to 2MB)
2. maxParameterCount on Connector (default to 1000)
3. maxHeaderCount on Connector (default to 100)
4. maxHttpRequestHeaderSize on Connector (default to 8K)
5. maxRequestSize on MCE (runtime: default to maxPostSize)
6. maxFileSize on MCE (runtime: default to maxPostSize)
7. Each part header size are limited (2K or 8K?)
8. maxPartHeaderSize on Connector (default to 512)
9. maxPartCount on Connector (default to 50)
Per rfc7578 section 4.8, once PR https://github.com/apache/tomcat/pull/869 /
https://github.com/apache/commons-fileupload/pull/421 were accepted, maximum
number of part headers for each part is 3.
Similar to maxHeaderCount and maxHttpRequestHeaderSize, maybe is clearly that
if we introduce maxPartHeaderCount to limit total part-headers of all parts and
change maxPartHeaderSize to total size of all parts' headers.
maxPartHeaderCount + maxPartHeaderSize to rule all headers of all parts.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #10 from 123haynes@gmail.com ---
(In reply to Remy Maucherat from comment #9)
> The problem seems that you are not using multipart very efficiently. If you
> have trivial flag parameters to pass, then URL params work, for starters.
> Although multipart happened to work in all cases, this was an assumption
> that maybe was not very reasonable.
I disagree with this.
As soon as you use a form with a fileuplod in it you will normally use the
attribute enctype="multipart/form-data".
With the new default limit that means every form with that enctype and more
than 10 fields will break.
For me this change broke several of my apps and i had to track down what the
hell changed in the tomcat codebase.
I'm ok with introducing new limits in general, but this was done in a minor
release without any warning to the users.
Even the notable changes do not mention new default limits and just reads
"Provide finer grained control of multi-part request processing via two new
attributes on the Connector element."
No mention of new, enforced limits at all.
At the very least this change should be prominently mentioned in the notable
changes section of the release.
Ideally I'd expect to introduce these options with much higher default values
that don't break apps and then reduce them in a major release when people are
expecting it.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #23 from Remy Maucherat <re...@apache.org> ---
For the record, +1 for 50 as the new default for maxPartCount.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|WONTFIX |---
Status|RESOLVED |REOPENED
--- Comment #12 from Mark Thomas <ma...@apache.org> ---
Now the associated CVEs are public, it can be revealed that this change was in
response to CVE-2025-48976 and CVE-2025-48988.
Combined, these CVEs could trigger an OOME leading to a DoS.
With a carefully crafted request, the memory usage is:
Part Header Size (was 10kB, now 512)
x
Maximum number of Parts per request (was 1000, now 10)
x
Maximum number of concurrent request (8192)
x
2 (due to the internal implementation)
x
2 (if running on Java 8 - so Tomcat 9 only)
That made the worst case memory usage 10kb x ~1k x 8k x 4 = 320Gb
The changes we introduced reduced this to a more manageable 0.5k x 10 x 8k x 4
= 160Mb
Yes, the part limit of 10 is too low for some use cases but increasing it to
100 is probably going to far.
Happy to discuss how we can improve things for the July release round. A few
options to consider for starters:
a) We could make the default maxPartCount 20 by default but halve it for Tomcat
9 if running on Java 8.
b) Increase maxPartCount to something else. Options here depend on what we
consider to be reasonable for default memory requirements. If we think 1Gb is
reasonable maxPartCount could go as high as 60 (or 120 if we include optional
a) as well)
c) include part headers in the maxPostSize calculation? With a 2Mb default that
leads to around 16Gb memory usage which is too high. maxPostSize would need to
come down to ~200k for that to work - that might be too low for a default.
What do folks think?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 69710] FileCountLimitExceededException is thrown in version 11.0.8
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #11 from Carlos Cerrillo <cc...@gmail.com> ---
I also think this shouldn’t have been included as a minor change, or without
any heads-up about it, because it breaks a lot of default apps. I think there
should be a pretty high limit to keep backwards compatibility, and if you want
to reduce it, you should do it in a major version, that way there’s enough room
to adjust.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org