https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #34 from Chen Jp ---
(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 b
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
clement.demoul...@faveod.com changed:
What|Removed |Added
CC||clement.demoul...@faveod.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #33 from Christopher Schultz ---
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 c
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #32 from Mark Thomas ---
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 heade
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #31 from Chen Jp ---
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. maxHttpR
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #29 from Remy Maucherat ---
(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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #28 from Mark Thomas ---
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #27 from Remy Maucherat ---
(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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #26 from Mark Thomas ---
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 change
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #25 from Paolo B. ---
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-st
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #23 from Remy Maucherat ---
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.
-
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #24 from Mark Thomas ---
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #22 from Brice ---
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 existin
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #21 from Remy Maucherat ---
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 ve
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.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #19 from Rainer Jung ---
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 t
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #18 from 123hay...@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 pr
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #17 from Remy Maucherat ---
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 thi
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #16 from Carlos Cerrillo ---
I believe that any value between 30 and 60
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #15 from Mark Thomas ---
Increasing it to what?
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr..
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #14 from Carlos Cerrillo ---
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.
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #13 from Remy Maucherat ---
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 mitig
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Mark Thomas changed:
What|Removed |Added
Resolution|WONTFIX |---
Status|RESOLVED
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Fabian Hahn changed:
What|Removed |Added
Priority|P2 |P1
CC|
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #11 from Carlos Cerrillo ---
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #10 from 123hay...@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.
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #9 from Remy Maucherat ---
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #8 from Aleksandr Beliakov ---
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 t
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #7 from Christopher Schultz ---
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 applica
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #6 from Aleksandr Beliakov ---
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..
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #5 from Remy Maucherat ---
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.
---
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #4 from Aleksandr Beliakov ---
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.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
--- Comment #3 from Aleksandr Beliakov ---
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.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Mark Thomas changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
Aleksandr Beliakov changed:
What|Removed |Added
OS||All
--- Comment #1 from Aleksandr
36 matches
Mail list logo
