https://bz.apache.org/bugzilla/show_bug.cgi?id=69748
Remy Maucherat changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #4 from Remy
https://bz.apache.org/bugzilla/show_bug.cgi?id=69752
--- Comment #3 from Remy Maucherat ---
Indeed, it definitely logs what is deployed, so it will be obvious there is
something to fix. If we try to fix these kind of items, then I am sure we will
run into someone reporting a regression because
https://bz.apache.org/bugzilla/show_bug.cgi?id=69752
--- Comment #2 from Mark Thomas ---
Generally, Tomcat doesn't prevent valid but potentially foolish configuration
settings. Such "protection" would add a significant amount of bloat to the
codebase and, given the size and d
https://bz.apache.org/bugzilla/show_bug.cgi?id=69752
--- Comment #1 from Don't show my email ---
NOTE:
The Tomcat docs for the HOST Element are not naming what happens with an empty
option is used, nor is there a security risk advise for this case. I suggest to
change this for all TC ver
https://bz.apache.org/bugzilla/show_bug.cgi?id=69752
Bug ID: 69752
Summary: HOST appBase = "" accepted as valid option
Product: Tomcat 9
Version: 9.0.102
Hardware: PC
OS: Linux
Status: NEW
Sever
https://bz.apache.org/bugzilla/show_bug.cgi?id=69748
--- Comment #3 from Nagendra ---
When a request is processed synchronously, Tomcat works fine as follows.
1. Handles the request and sends a response.
2. Waits for the next request from the same client for a duration defined by
https://bz.apache.org/bugzilla/show_bug.cgi?id=69748
--- Comment #2 from Remy Maucherat ---
The keep alive you are thinking about probably does not apply to async. Async
is a single request (and it uses its own timeout usually), while keep alive is
the amount of time a connection stays open
https://bz.apache.org/bugzilla/show_bug.cgi?id=69748
Christopher Schultz changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from
https://bz.apache.org/bugzilla/show_bug.cgi?id=69747
Christopher Schultz changed:
What|Removed |Added
OS||All
--- Comment #1 from
https://bz.apache.org/bugzilla/show_bug.cgi?id=69747
Christopher Schultz changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=69748
Bug ID: 69748
Summary: keep-alive value is not being honoured in async
servlet
Product: Tomcat 9
Version: 9.0.98
Hardware: PC
OS: Mac OS X 10.1
https://bz.apache.org/bugzilla/show_bug.cgi?id=69747
Bug ID: 69747
Summary: Incorrect reference to StaticMembershipInterceptor
instead of StaticMembershipService in
cluster-howto.xml
Product: Tomcat 9
Version
https://bz.apache.org/bugzilla/show_bug.cgi?id=69617
--- Comment #5 from Cley Friesen ---
Regarding the maxHttpRequestHeaderSize setting, has anyone encountered high
heap memory usage related to excessively large headers? I've seen instances
where aggressive clients sending huge co
https://bz.apache.org/bugzilla/show_bug.cgi?id=69739
Chuck Caldarale changed:
What|Removed |Added
Resolution|--- |INVALID
Summary|https
https://bz.apache.org/bugzilla/show_bug.cgi?id=69739
--- Comment #2 from Chuck Caldarale ---
The content of attachment 40068 has been deleted for the following reason:
Spam
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=69739
--- Comment #1 from trandau ---
Created attachment 40068
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40068&action=edit
https://trandau.net
https://trandau.net
--
You are receiving this mail because:
You are the assignee
https://bz.apache.org/bugzilla/show_bug.cgi?id=69739
Bug ID: 69739
Summary: https://trandau.net
Product: Tomcat Native
Version: unspecified
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #15 from Christopher Schultz ---
(In reply to Remy Maucherat from comment #13)
> (In reply to Christopher Schultz from comment #12)
> > I mentioned this in a previous comment. If the file requested exists, I
> > thi
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
Remy Maucherat changed:
What|Removed |Added
Attachment #40058|0 |1
is obsolete
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #13 from Remy Maucherat ---
(In reply to Christopher Schultz from comment #12)
> (In reply to Michael Osipov from comment #11)
> > (In reply to Christopher Schultz from comment #8)
> > > I think it's reas
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #12 from Christopher Schultz ---
(In reply to Michael Osipov from comment #11)
> (In reply to Christopher Schultz from comment #8)
> > I think it's reasonable to use the JVM's default locale when there is none
&
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
Michael Osipov changed:
What|Removed |Added
CC||micha...@apache.org
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #11 from Michael Osipov ---
(In reply to Christopher Schultz from comment #8)
> (In reply to Remy Maucherat from comment #7)
> > (In reply to Michael Osipov from comment #6)
> > > (In reply to Remy Maucher
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
Christopher Schultz changed:
What|Removed |Added
Attachment #40056|0 |1
is obsolete
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #9 from Christopher Schultz ---
Comments on the patch (latest is attachment #40058 at the time of this
writing). I have only read the patch, not run it.
1. I believe content-negotiation in mod_negotiation is only performed if the
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #8 from Christopher Schultz ---
(In reply to Remy Maucherat from comment #7)
> (In reply to Michael Osipov from comment #6)
> > (In reply to Remy Maucherat from comment #3)
> > > I would have thought this would be
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #7 from Remy Maucherat ---
(In reply to Michael Osipov from comment #6)
> (In reply to Remy Maucherat from comment #3)
> > I would have thought this would be (another) feature in default servlet.
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #6 from Michael Osipov ---
(In reply to Remy Maucherat from comment #3)
> I would have thought this would be (another) feature in default servlet.
> I believe ServletRequest.getLocales() will return a sorted list of l
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
Remy Maucherat changed:
What|Removed |Added
Attachment #40057|0 |1
is obsolete
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #4 from Remy Maucherat ---
Created attachment 40057
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40057&action=edit
Accept-Language in default servlet
Would this be an acceptable impl for simple Accpet-Language sup
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #3 from Remy Maucherat ---
I would have thought this would be (another) feature in default servlet.
I believe ServletRequest.getLocales() will return a sorted list of locales
according to the quality from the Accept-Language header
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #2 from Christopher Schultz ---
Created attachment 40056
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40056&action=edit
Initial implementation as a servlet Filter
This is my first effort at a ContentNegotiatio
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
fabstz...@yahoo.fr changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
--- Comment #1 from fabstz...@yahoo.fr ---
See also: https://lists.apache.org/thread/2l559qcqdl5qhwgc7p0sdxww2v9b1pk5
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735
Bug ID: 69735
Summary: Support content negotiation for Accept-Language
(static pages)
Product: Tomcat 11
Version: unspecified
Hardware: PC
OS: Linux
https://bz.apache.org/bugzilla/show_bug.cgi?id=69733
Christopher Schultz changed:
What|Removed |Added
Summary|https://mivja.com |SPAM SPAM SPAM SPAM
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=69734
Chuck Caldarale changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=69734
Bug ID: 69734
Summary: Systemd service
Product: Tomcat 10
Version: 10.1.42
Hardware: HP
OS: Linux
Status: NEW
Severity: normal
Priority: P2
https://bz.apache.org/bugzilla/show_bug.cgi?id=69733
Chuck Caldarale changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bz.apache.org/bugzilla/show_bug.cgi?id=69733
--- Comment #2 from Chuck Caldarale ---
The content of attachment 40054 has been deleted for the following reason:
Spam
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=69733
--- Comment #1 from Noah Fateh ---
Created attachment 40054
--> https://bz.apache.org/bugzilla/attachment.cgi?id=40054&action=edit
https://mivja.com
--
You are receiving this mail because:
You are the assignee for
https://bz.apache.org/bugzilla/show_bug.cgi?id=69733
Bug ID: 69733
Summary: https://mivja.com
Product: Tomcat Native
Version: unspecified
Hardware: PC
OS: Windows XP
Status: NEW
Severity: normal
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
> backwa
https://bz.apache.org/bugzilla/show_bug.cgi?id=69731
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=69731
--- Comment #3 from Mark Thomas ---
I have a clean fix for this. I just need to write some unit tests and I'll be
ready to merge it.
--
You are receiving this mail because:
You are the assignee for th
https://bz.apache.org/bugzilla/show_bug.cgi?id=56148
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=69710
clement.demoul...@faveod.com changed:
What|Removed |Added
CC||clement.demoul
https://bz.apache.org/bugzilla/show_bug.cgi?id=69731
naozumi.taromaru...@nttdata.com changed:
What|Removed |Added
Summary|Incorrect count of |Incorrect count of
https://bz.apache.org/bugzilla/show_bug.cgi?id=69731
naozumi.taromaru...@nttdata.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=56148
--- Comment #20 from Christopher Schultz ---
I'm not sure investing a lot of energy in anything OCSP-related is worth it any
more.
https://letsencrypt.org/2024/12/05/ending-ocsp/
I know it sounds crazy, but we are basically going back t
https://bz.apache.org/bugzilla/show_bug.cgi?id=56148
--- Comment #19 from logo ---
Hi @Mark,
I have no ways to fix this myself (provide patch).
Any chance to get this fixed? It's been a while that this is happily working in
JSSE :-) .
Is this actually available in 10.1ff, Native 2.0?
https://bz.apache.org/bugzilla/show_bug.cgi?id=69731
Remy Maucherat changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=69731
Bug ID: 69731
Summary: Incorrect count of maxParameterCount (double count)
when executing req.getParameter(name) after
request.getPart()
Product: Tomcat 9
https://bz.apache.org/bugzilla/show_bug.cgi?id=65901
Chuck Caldarale changed:
What|Removed |Added
Version|unspecified |1.2.48
--
You are receiving this
https://bz.apache.org/bugzilla/show_bug.cgi?id=65901
l...@educationalnetworks.net changed:
What|Removed |Added
Version|1.2.48 |unspecified
--
You are
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
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
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
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=69728
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=69728
--- Comment #2 from Guillaume Darmont ---
Ok I see now.
Thanks for your answer, and having a look at the log.
Guillaume
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=69728
--- Comment #1 from Mark Thomas ---
Optional verification and optional presence are the same thing.
That said, I do think the log message isn't quite right.
The issue is the HTTP/2 doesn't permit re-handshaking (TLS 1.2) or
post
https://bz.apache.org/bugzilla/show_bug.cgi?id=69728
Bug ID: 69728
Summary: TLS with H2 - Weird log - Confusion between optional
client certificate and optional verification?
Product: Tomcat 10
Version: 10.1.31
Hardware
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901
Matafagafo changed:
What|Removed |Added
CC||matafag...@gmail.com
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=69713
Matafagafo changed:
What|Removed |Added
CC||matafag...@gmail.com
--
You are
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 abo
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
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
&g
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69576
--- Comment #22 from evelynwang0...@gmail.com ---
(In reply to Thomas F from comment #13)
> When will Tomcat 10.1.36 with this critical fix be released?
>
> This website:
> https://versionlog.com/apache-tomcat/10.1/ https://grade-c
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69721
Christopher Schultz changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://bz.apache.org/bugzilla/show_bug.cgi?id=69722
Aftab Zia changed:
What|Removed |Added
Blocks||69723
Referenced Bugs:
https
https://bz.apache.org/bugzilla/show_bug.cgi?id=69723
Bug ID: 69723
Summary: Self
Product: POI
Version: 5.4.x-dev
Hardware: All
OS: OpenBSD
Status: NEW
Severity: major
Priority: P2
https://bz.apache.org/bugzilla/show_bug.cgi?id=69722
Bug ID: 69722
Summary: Self
Product: Tomcat 11
Version: 11.0.0-M1
Hardware: All
OS: OpenBSD
Status: NEW
Severity: minor
Priority: P2
https://bz.apache.org/bugzilla/show_bug.cgi?id=69722
Aftab Zia changed:
What|Removed |Added
CC||sabirsaee...@gmail.com
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=69721
--- Comment #6 from Paolo B. ---
Ok!
Now I understand the limit of me example:
JSF always add
2 input hidden + input type submit
If you set maxPartCount="5"
You can upload only 2 files...
Back to the problem, this new para
https://bz.apache.org/bugzilla/show_bug.cgi?id=69721
--- Comment #5 from Remy Maucherat ---
maxPartCount is the number of total parts of the multipart, not the number of
files.
These changes are about the following CVEs (both rathed Important):
- CVE-2025-48976 Apache Tomcat - DoS in Commons
https://bz.apache.org/bugzilla/show_bug.cgi?id=69721
--- Comment #4 from Christoph Strasser ---
Think this is the reason:
https://github.com/apache/tomcat/commit/e34fe96ef8ee782b0e56b64358e8dc57cbe336a6#diff-57d2f0a72170743f6c3687a48997b2aa37d8d209efe200f00a0b9dc51fc7e572
No further opinion on
https://bz.apache.org/bugzilla/show_bug.cgi?id=69721
--- Comment #3 from Christoph Strasser ---
Up to 10.1.41 this just worked. (It´s covered by integration-tests which run
every night for PrimeFaces.)
With 10.1.42 it´s now broken.
As far as i looked into this there 10.1.42 switched to a newer
https://bz.apache.org/bugzilla/show_bug.cgi?id=69721
Paolo B. changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=69721
--- Comment #2 from Paolo B. ---
if you configure on server.xml
maxParameterCount="1"
maxPartCount="5"
maxPartHeaderSize="-1"
The limit seems to be 2 files
--
You are receiving this mail
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=69721
Mark Thomas changed:
What|Removed |Added
Severity|critical|normal
Status|NEW
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=69721
Bug ID: 69721
Summary: The new Connector parameter 'maxPartCount' is not
calculated correctly
Product: Tomcat 10
Version: 10.1.42
Hardware: PC
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=69717
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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 ou
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 multipar
https://bz.apache.org/bugzilla/show_bug.cgi?id=69717
--- Comment #2 from Jonas Verhofsté ---
Or config validation should fail when the param has a trailing slash?
It just silently not working and that not being documented anywhere is still a
regression caused by the fix for the CVE. :)
--
You
https://bz.apache.org/bugzilla/show_bug.cgi?id=69717
--- Comment #1 from Remy Maucherat ---
Please read: "Moderate: Security constraint bypass for PreResources and
PostResources CVE-2025-49125" https://tomcat.apache.org/security-9.html
Stripping the tra
https://bz.apache.org/bugzilla/show_bug.cgi?id=69717
Bug ID: 69717
Summary: DirResourceSet breaks with trailing slash on
webAppMount
Product: Tomcat 9
Version: 9.0.106
Hardware: PC
OS: Linux
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 facto
https://bz.apache.org/bugzilla/show_bug.cgi?id=69713
--- Comment #4 from Mark Thomas ---
Fixed in:
- 11.0.x for 11.0.9 onwards
- 10.1.x for 10.1.43 onwards
- 9.0.x for 9.0.107 onwards
--
You are receiving this mail because:
You are the assignee for the bug
https://bz.apache.org/bugzilla/show_bug.cgi?id=69713
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
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
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
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
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
1 - 100 of 35118 matches
Mail list logo
