[PR] logging doc - fix package for OneLineFormatter [tomcat]
dgriffith-lx opened a new pull request, #874: URL: https://github.com/apache/tomcat/pull/874 Update package for OneLineFormatter to match [logging.properties](https://github.com/apache/tomcat/blob/9.0.x/conf/logging.properties) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] logging doc - fix package for OneLineFormatter [tomcat]
ChristopherSchultz merged PR #874: URL: https://github.com/apache/tomcat/pull/874 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 9.0.x updated: logging doc - fix package for OneLineFormatter
This is an automated email from the ASF dual-hosted git repository.
schultz pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/9.0.x by this push:
new 258261ce55 logging doc - fix package for OneLineFormatter
258261ce55 is described below
commit 258261ce5528b72e35d259712be48cbf0d8a8260
Author: dgriffith-lx <38105311+dgriffith...@users.noreply.github.com>
AuthorDate: Thu Jul 10 10:01:56 2025 -0400
logging doc - fix package for OneLineFormatter
---
webapps/docs/logging.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/webapps/docs/logging.xml b/webapps/docs/logging.xml
index b7b8c0d9a5..e258781203 100644
--- a/webapps/docs/logging.xml
+++ b/webapps/docs/logging.xml
@@ -354,7 +354,7 @@ java.util.logging.ConsoleHandler.level=ALL
3manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8
@@ -391,7 +391,7 @@ org.apache.juli.AsyncFileHandler.prefix =
${classloader.webappName}.
org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8]]>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: logging doc - fix package for OneLineFormatter
This is an automated email from the ASF dual-hosted git repository.
schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/main by this push:
new 18850add22 logging doc - fix package for OneLineFormatter
18850add22 is described below
commit 18850add22184338876399c1215f3242384603c0
Author: dgriffith-lx <38105311+dgriffith...@users.noreply.github.com>
AuthorDate: Thu Jul 10 10:01:56 2025 -0400
logging doc - fix package for OneLineFormatter
---
webapps/docs/logging.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/webapps/docs/logging.xml b/webapps/docs/logging.xml
index 32b5650843..d3489c9bf0 100644
--- a/webapps/docs/logging.xml
+++ b/webapps/docs/logging.xml
@@ -354,7 +354,7 @@ java.util.logging.ConsoleHandler.level=ALL
3manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8
@@ -391,7 +391,7 @@ org.apache.juli.AsyncFileHandler.prefix =
${classloader.webappName}.
org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8]]>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 11.0.x updated: logging doc - fix package for OneLineFormatter
This is an automated email from the ASF dual-hosted git repository.
schultz pushed a commit to branch 11.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/11.0.x by this push:
new fd0eac9e76 logging doc - fix package for OneLineFormatter
fd0eac9e76 is described below
commit fd0eac9e76fc64e4d89e98b66198ff7d95ffb7e6
Author: dgriffith-lx <38105311+dgriffith...@users.noreply.github.com>
AuthorDate: Thu Jul 10 10:01:56 2025 -0400
logging doc - fix package for OneLineFormatter
---
webapps/docs/logging.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/webapps/docs/logging.xml b/webapps/docs/logging.xml
index c8473288ee..f02bb4654a 100644
--- a/webapps/docs/logging.xml
+++ b/webapps/docs/logging.xml
@@ -354,7 +354,7 @@ java.util.logging.ConsoleHandler.level=ALL
3manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8
@@ -391,7 +391,7 @@ org.apache.juli.AsyncFileHandler.prefix =
${classloader.webappName}.
org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8]]>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 10.1.x updated: logging doc - fix package for OneLineFormatter
This is an automated email from the ASF dual-hosted git repository.
schultz pushed a commit to branch 10.1.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/10.1.x by this push:
new 1d65c24a76 logging doc - fix package for OneLineFormatter
1d65c24a76 is described below
commit 1d65c24a768fd66e7b759fef147d80f7d712fc39
Author: dgriffith-lx <38105311+dgriffith...@users.noreply.github.com>
AuthorDate: Thu Jul 10 10:01:56 2025 -0400
logging doc - fix package for OneLineFormatter
---
webapps/docs/logging.xml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/webapps/docs/logging.xml b/webapps/docs/logging.xml
index fa33e0ef0a..3b23d92dfa 100644
--- a/webapps/docs/logging.xml
+++ b/webapps/docs/logging.xml
@@ -354,7 +354,7 @@ java.util.logging.ConsoleHandler.level=ALL
3manager.org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8
@@ -391,7 +391,7 @@ org.apache.juli.AsyncFileHandler.prefix =
${classloader.webappName}.
org.apache.juli.AsyncFileHandler.encoding = UTF-8
java.util.logging.ConsoleHandler.level = ALL
-java.util.logging.ConsoleHandler.formatter = java.util.logging.OneLineFormatter
+java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter
java.util.logging.ConsoleHandler.encoding = UTF-8]]>
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 > > think it should be returned with no content-negotiation. > > I would need a source for that since it would seem highly unlikely. The > default resource would be there if no locales match (IMO). https://httpd.apache.org/docs/2.4/mod/mod_negotiation.html#multiviews " If the server receives a request for /some/dir/foo and /some/dir/foo does **not** exist, then the server reads the directory looking for all files named foo.* [...] " > > In that case, the > > presence of the Accept-Language is not relevant, nor is the default locale > > of the JVM. > > That's not the issue, the problem is that if there's no Accept-Language > header, then getLocales will have the local JVM locale. If content-negotiation is not performed (per the above quote), then the return value of HttpServletRequest.getLocales is not relevant. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 > > presented by the client. The alternative is to perform zero > > content-negotiation if an Accept-Language header is not present which would > > perfectly in-line with the HTTP specification. > > I don't know. My servers haven de_DE.UTF-8 and consider index.html, > index.html.de are present, but not .fr and fr is requests why is then > index.html.de delivered? I would expect index.html to be delivered. Just > like the Apache module would do. I mentioned this in a previous comment. If the file requested exists, I think it should be returned with no content-negotiation. In that case, the presence of the Accept-Language is not relevant, nor is the default locale of the JVM. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 reasonable to use the JVM's default locale when there is none > > > presented by the client. The alternative is to perform zero > > > content-negotiation if an Accept-Language header is not present which > > > would > > > perfectly in-line with the HTTP specification. > > > > I don't know. My servers haven de_DE.UTF-8 and consider index.html, > > index.html.de are present, but not .fr and fr is requests why is then > > index.html.de delivered? I would expect index.html to be delivered. Just > > like the Apache module would do. > > I mentioned this in a previous comment. If the file requested exists, I > think it should be returned with no content-negotiation. I would need a source for that since it would seem highly unlikely. The default resource would be there if no locales match (IMO). > In that case, the > presence of the Accept-Language is not relevant, nor is the default locale > of the JVM. That's not the issue, the problem is that if there's no Accept-Language header, then getLocales will have the local JVM locale. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735 Remy Maucherat changed: What|Removed |Added Attachment #40058|0 |1 is obsolete|| --- Comment #14 from Remy Maucherat --- Created attachment 40059 --> https://bz.apache.org/bugzilla/attachment.cgi?id=40059&action=edit Accept-Language in default servlet -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 (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. So using the > > > list > > > to go through possible lookups would work. > > > > Attention: That method will also return the JVM's locale as well. As far as > > I remember this was mandated by the Server API spec. > > The javadoc is (the implementation matches it): > /** > * Returns an Enumeration of Locale objects > indicating, in decreasing order starting with > * the preferred locale, the locales that are acceptable to the client > based on the Accept-Language header. If the > * client request doesn't provide an Accept-Language header, this method > returns an Enumeration > * containing one Locale, the default locale for the server. > * > * @return an Enumeration of preferred Locale > objects for the client > */ > Enumeration getLocales(); > > So the question is if that case where it returns the local JVM's default > locale needs to be handled. It confused me a little initially so I messed up > the first patch version. > Maybe add a check to see if an Accept-Language header is present. I think it's reasonable to use the JVM's default locale when there is none presented by the client. The alternative is to perform zero content-negotiation if an Accept-Language header is not present which would perfectly in-line with the HTTP specification. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 original resource does not exist. I haven't done very careful checking on this. The current patch always performs it for all requests, even if the original request would have found exactly one file. The Filter only looked for other files if the original resource appeared to be missing. It would be good to understand user expectations in order to potentially improve performance. 2. One advantage of the Filter was that it could be bound only to certain URL patterns, while this DefaultServlet implementation has a single on/off switch. It would be nice to be able to enable/disable this behavior under some circumstances. For example, "only for index.html files" or "only in _this_ directory". We could implement some complicated system of configuration, or we could use Filters to enable content-negotiation by setting a request attribute before the DefaultServlet runs. We may want to package such a Filter along with Tomcat that can easily be used by end-users, but I think it would be trivial and the complexity comes from how the Filter is configured. 3. The DefaultServlet does not set the Vary header, which I think is important. 4. The unit test appears to be looking for index.html.fr, but the Accept-Language in the request prefers German. Also, the file index.html.fr doesn't appear to be a part of the patch, and I don't see any mock-objects that would suggest that the file is loaded from non-disk. Perhaps I don't understand how the test works. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735 Christopher Schultz changed: What|Removed |Added Attachment #40056|0 |1 is obsolete|| --- Comment #10 from Christopher Schultz --- Comment on attachment 40056 --> https://bz.apache.org/bugzilla/attachment.cgi?id=40056 Initial implementation as a servlet Filter No need for this attachment anymore. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 locales > according to the quality from the Accept-Language header. So using the list > to go through possible lookups would work. Attention: That method will also return the JVM's locale as well. As far as I remember this was mandated by the Server API spec. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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. > > I believe ServletRequest.getLocales() will return a sorted list of locales > > according to the quality from the Accept-Language header. So using the list > > to go through possible lookups would work. > > Attention: That method will also return the JVM's locale as well. As far as > I remember this was mandated by the Server API spec. The javadoc is (the implementation matches it): /** * Returns an Enumeration of Locale objects indicating, in decreasing order starting with * the preferred locale, the locales that are acceptable to the client based on the Accept-Language header. If the * client request doesn't provide an Accept-Language header, this method returns an Enumeration * containing one Locale, the default locale for the server. * * @return an Enumeration of preferred Locale objects for the client */ Enumeration getLocales(); So the question is if that case where it returns the local JVM's default locale needs to be handled. It confused me a little initially so I messed up the first patch version. Maybe add a check to see if an Accept-Language header is present. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 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 > > > > locales > > > > according to the quality from the Accept-Language header. So using the > > > > list > > > > to go through possible lookups would work. > > > > > > Attention: That method will also return the JVM's locale as well. As far > > > as > > > I remember this was mandated by the Server API spec. > > > > The javadoc is (the implementation matches it): > > /** > > * Returns an Enumeration of Locale objects > > indicating, in decreasing order starting with > > * the preferred locale, the locales that are acceptable to the client > > based on the Accept-Language header. If the > > * client request doesn't provide an Accept-Language header, this method > > returns an Enumeration > > * containing one Locale, the default locale for the > > server. > > * > > * @return an Enumeration of preferred Locale > > objects for the client > > */ > > Enumeration getLocales(); > > > > So the question is if that case where it returns the local JVM's default > > locale needs to be handled. It confused me a little initially so I messed up > > the first patch version. > > Maybe add a check to see if an Accept-Language header is present. > > I think it's reasonable to use the JVM's default locale when there is none > presented by the client. The alternative is to perform zero > content-negotiation if an Accept-Language header is not present which would > perfectly in-line with the HTTP specification. I don't know. My servers haven de_DE.UTF-8 and consider index.html, index.html.de are present, but not .fr and fr is requests why is then index.html.de delivered? I would expect index.html to be delivered. Just like the Apache module would do. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
https://bz.apache.org/bugzilla/show_bug.cgi?id=69735 Remy Maucherat changed: What|Removed |Added Attachment #40057|0 |1 is obsolete|| --- Comment #5 from Remy Maucherat --- Created attachment 40058 --> https://bz.apache.org/bugzilla/attachment.cgi?id=40058&action=edit Accept-Language in default servlet Revised (the default locale only gets added if the list in empty) and test. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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. So using the list to go through possible lookups would work. -- 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
[Bug 69735] Support content negotiation for Accept-Language (static pages)
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 support in the default servlet ? Testcase to be added ... Other features like the Accept header are not specified by the Servlet specification, and it's not in o.a.tomcat.util.http.parser, so I'm pretty sure this should be avoided at this time. -- 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
[SECURITY] CVE-2025-53506 Apache Tomcat - DoS in HTP/2
CVE-2025-53506 Apache Tomcat - DoS in HTTP/2 Severity: High Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.8 Apache Tomcat 10.1.0-M1 to 10.1.42 Apache Tomcat 9.0.0.M1 to 9.0.106 Description: An uncontrolled resource consumption vulnerability if an HTTP/2 client did not acknowledge the initial settings frame that reduces the maximum permitted concurrent streams could result in a DoS. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.9 or later - Upgrade to Apache Tomcat 10.1.32 or later - Upgrade to Apache Tomcat 9.0.107 or later Credit: The vulnerability was identified by Kanatoko History: 2025-07-10 Original advisory References: [1] https://tomcat.apache.org/security-11.html [2] https://tomcat.apache.org/security-10.html [3] https://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2025-52434 Apache Tomcat -APR/native Connector crash leading to DoS
CVE-2025-49125 Apache Tomcat - APR/Native Connector crash leading to DoS Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.105 Description: A race condition on connection close could trigger a JVM crash when using the APR/Native connector leading to a DoS. This was particularly noticeable with client initiated closes of HTTP/2 connections. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 9.0.107 or later Credit: Nacl, 12SqweR, WHOAMI, yyzmoo History: 2025-07-10 Original advisory References: [1] https://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1927120 [1/3] - in /tomcat/site/trunk: docs/oldnews-2024.html docs/security-10.html docs/security-11.html docs/security-9.html xdocs/security-10.xml xdocs/security-11.xml xdocs/security-9
Author: markt Date: Thu Jul 10 18:55:09 2025 New Revision: 1927120 URL: http://svn.apache.org/viewvc?rev=1927120&view=rev Log: Update site with latest CVEs Modified: tomcat/site/trunk/docs/oldnews-2024.html tomcat/site/trunk/docs/security-10.html tomcat/site/trunk/docs/security-11.html tomcat/site/trunk/docs/security-9.html tomcat/site/trunk/xdocs/security-10.xml tomcat/site/trunk/xdocs/security-11.xml tomcat/site/trunk/xdocs/security-9.xml tomcat/site/trunk/xdocs/sitemap-main.xml - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1927120 [2/3] - in /tomcat/site/trunk: docs/oldnews-2024.html docs/security-10.html docs/security-11.html docs/security-9.html xdocs/security-10.xml xdocs/security-11.xml xdocs/security-9
Modified: tomcat/site/trunk/docs/oldnews-2024.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/oldnews-2024.html?rev=1927120&r1=1927119&r2=1927120&view=diff == --- tomcat/site/trunk/docs/oldnews-2024.html (original) +++ tomcat/site/trunk/docs/oldnews-2024.html Thu Jul 10 18:55:09 2025 @@ -1,1292 +1,1292 @@ - -Apache Tomcat® - Old news!https://www.apachecon.com/event-images/snippet.js";>http://tomcat.apache.org/";>Apache Tomcat®https://www.apache.org/foundation/contributing.html"; target="_blank" class="pull-left">https://www.apache.org/images/SupportApache-small.png " class="support-asf" alt="Support Apache">http://www.apache.org/"; target="_blank" class="pull-left">https://www.google.com/search"; method="get">GOApache TomcatHomeTaglibsMaven PluginDownloadWhich version?https://tomcat.apache.org/download-11.c gi">Tomcat 11https://tomcat.apache.org/download-10.cgi";>Tomcat 10https://tomcat.apache.org/download-90.cgi";>Tomcat 9https://tomcat.apache.org/download-migration.cgi";>Tomcat Migration Tool for Jakarta EEhttps://tomcat.apache.org/download-connectors.cgi";>Tomcat Connectorshttps://tomcat.apache.org/download-native.cgi";>Tomcat Nativehttps://tomcat.apache.org/download-taglibs.cgi";>Taglibshttps://archive.apache.org/dist/tomcat/";>ArchivesDocumentationTomcat 11.0Tomcat 10.1Tomcat 9.0UpgradingTomcat ConnectorsTomcat Native 2< /a>Tomcat Native 1.3https://cwiki.apache.org/confluence/display/TOMCAT";>WikiMigration GuidePresentationshttps://cwiki.apache.org/confluence/x/Bi8lBg";>SpecificationsProblems?Security ReportsFind helphttps://cwiki.apache.org/confluence/display/TOMCAT/FAQ";>FAQMailing ListsBug DatabaseIRCGet InvolvedOverviewSource codeBuildbotToolsMediahttps://twitter.com/t heapachetomcat">Twitterhttps://www.youtube.com/c/ApacheTomcatOfficial";>YouTubehttps://blogs.apache.org/tomcat/";>BlogMiscWho We Arehttps://www.redbubble.com/people/comdev/works/30885254-apache-tomcat";>SwagHeritagehttp://www.apache.org";>Apache HomeResourcesContactLegalhttps://privacy.apache.org/policies/privacy-policy-public.html";>Privacyhttps://www.apache.org/foundation/contributing.html";>Support Apachehttps://www.apache.org/foundation/sponsorship.html";>Sponsorshiphttp://www.apache.org/foundation/thanks.html";>Thankshttp://www.apache.org/licenses/";>LicenseContentOlder news -Announcements from previous years can be found here: - - year 2025 - year 2024 - year 2023 - year 2022 - year 2021 - year 2020 - year 2019 - year 2018 - year 2017 - year 2016 - year 2015 - year 2014 - year 2013 - year 2012 - year 2011 - year 2010 - -2024-12-09 Tomcat 11.0.2 Released - -The Apache Tomcat Project is proud to announce the release of version 11.0.2 -of Apache Tomcat. This release implements specifications that are part of the -Jakarta EE 11 platform. -Users of Tomcat 10 onwards should be aware that, as a result of the move from -Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse -Foundation, the primary package for all implemented APIs has changed from -javax.* to jakarta.*. This will almost certainly -require code changes to enable applications to migrate from Tomcat 9 and earlier -to Tomcat 10 and later. A -https://github.com/apache/tomcat-jakartaee-migration";>migration -tool is available to aid this process. -The notable changes in this release are: - -Add strong ETag support for the WebDAV and default servlet, which can -be enabled by using the useStrongETags init parameter with a value set -to true. The ETag generated will be a SHA-1 checksum of the resource -content. -Add support for RateLimit header fields for HTTP (RFC draft) in the -RateLimitFilter. Based on pull request #775 provided by Chenjp. -Update Tomcat's fork of Commons DBCP to 2.13.0. - - -Full details of these changes, and all the other changes, are available in the -Tomcat 11 -changelog. - - - -https://tomcat.apache.org/download-11.cgi";>Download - -2024-12-09 Tomcat 9.0.98 Released - -The Apache Tomcat Project is proud to announce the release of version 9.0.98 -of Apache Tomcat. This release implements specifications that are part of the -Java EE 8 platform. The notable changes compared to 9.0.97 include: - -Add strong ETag support for the WebDAV and default servlet, which can - be enabled by using the useStrongETags init parameter with a value set - to true. The ETag generated will be a SHA-1 checksum of the resource - content. -Add support for RateLimit header fields for HTTP (RFC draft) in the - RateLimitFilter. -Update Tomcat's fork of Commons DBCP to 2.13.0. - - -Full details of these changes, and all the other changes, are available in the -Tomcat 9 -changelog. - - - -https://tomcat.apache.org/download-90.cgi";>Download - -2024-12-09 Tomcat 10.1.34 Released - -The Apache Tomcat Project is proud to announce the release of version 10.1.34 -of Apache Tomcat. This release implements specifications
svn commit: r1927120 [3/3] - in /tomcat/site/trunk: docs/oldnews-2024.html docs/security-10.html docs/security-11.html docs/security-9.html xdocs/security-10.xml xdocs/security-11.xml xdocs/security-9
Modified: tomcat/site/trunk/docs/security-10.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-10.html?rev=1927120&r1=1927119&r2=1927120&view=diff == --- tomcat/site/trunk/docs/security-10.html (original) +++ tomcat/site/trunk/docs/security-10.html Thu Jul 10 18:55:09 2025 @@ -42,7 +42,36 @@ Table of Contents -Fixed in Apache Tomcat 10.1.42Fixed in Apache Tomcat 10.1.41Fixed in Apache Tomcat 10.1.40Fixed in Apache Tomcat 10.1.35Fixed in Apache Tomcat 10.1.34Fixed in Apache Tomcat 10.1.33Fixed in Apache Tomcat 10.1.31Fixed in Apache Tomcat 10.1.25Fixed in Apache Tomcat 10.1.19Fixed in Apache Tomcat 10.1.16Fixed in Apache Tomcat 10.1.14Fixed in Apache Tomcat 10.1.13Fixed in Apache Tomcat 10.1.9Fixed in Apache Tomcat 10.1.8Fixed in Apache Tomcat 10.1.6Fixed in Apache Tomcat 10.1.5Fixed in Apache Tomcat 10.1.2Fixed in Apache Tomcat 10.1.1Fixed in Apache Tomcat 10.0.27Fixed in Apache Tomcat 10.0.23Fixed in Apache Tomcat 10.1.0-M17Fixed in Apache Tomcat 10.0.21Fixed in Apache Tomcat 10.1.0-M15Fixed in Apache Tomcat 10.0.20Fixed in Apache Tomcat 10.1.0-M14Fixed in Apache Tomcat 10.0.16Fixed in Apache Tomcat 10.1.0-M10Fixed in Apache Tomcat 10.0.12Fixed in Apache Tomcat 10.1.0-M6Fixed in Apache Tomcat 10.0.7Fixed in Apache Tomcat 10.0.6Fixed in Apache Tomcat 10.0.5Fixed in Apache Tomcat 10.0.4Fixed in Apache Tomcat 10.0.2Fixed in Apache Tomcat 10.0.0-M10< /li>Fixed in Apache Tomcat 10.0.0-M8Fixed in Apache Tomcat 10.0.0-M7Fixed in Apache Tomcat 10.0.0-M6Fixed in Apache Tomcat 10.0.0-M5Not a vulnerability in Tomcat +Fixed in Apache Tomcat 10.1.43Fixed in Apache Tomcat 10.1.42Fixed in Apache Tomcat 10.1.41Fixed in Apache Tomcat 10.1.40Fixed in Apache Tomcat 10.1.35Fixed in Apache Tomcat 10.1.34Fixed in Apache Tomcat 10.1.33Fixed in Apache Tomcat 10.1.31Fixed in Apache Tomcat 10.1.25Fixed in Apache Tomcat 10.1.19Fixed in Apache Tomcat 10.1.16Fixed in Apache Tomcat 10.1.14Fixed in Apache Tomcat 10.1.13Fixed in Apache Tomcat 10.1.9Fixed in Apache Tomcat 10.1.8Fixed in Apache Tomcat 10.1.6Fixed in Apache Tomcat 10.1.5Fixed in Apache Tomcat 10.1.2Fixed in Apache Tomcat 10.1.1Fixed in Apache Tomcat 10.0.27Fixed in Apache Tomcat 10.0.23Fixed in Apache Tomcat 10.1.0-M17Fixed in Apache Tomcat 10.0.21Fixed in Apache Tomcat 10.1.0-M15Fixed in Apache Tomcat 10.0.20Fixed in Apache Tomcat 10.1.0-M14Fixed in Apache Tomcat 10.0.16Fixed in Apache Tomcat 10.1.0-M10Fixed in Apache Tomcat 10.0.12Fixed in Apache Tomcat 10.1.0-M6Fixed in Apache Tomcat 10.0.7Fixed in Apache Tomcat 10.0.6Fixed in Apache Tomcat 10.0.5Fixed in Apache Tomcat 10.0.4Fixed in Apache Tomcat 10.0.2Fixed in Apache Tomcat 10.0.0-M10Fixed in Apache Tomcat 10.0.0-M8Fixed in Apache Tomcat 10.0.0-M7Fixed in Apache Tomcat 10.0.0-M6Fixed in Apache Tomcat 10.0.0-M5Not a vulnerability in Tomcat + 2025-07-04 Fixed in Apache Tomcat 10.1.43 + +Low: DoS due to overflow in file upload limit + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-52520"; rel="nofollow">CVE-2025-52520 + +For some unlikely configurations of multipart upload, an Integer Overflow + vulnerability could lead to a DoS via bypassing of size limits. + +This was fixed with commit + https://github.com/apache/tomcat/commit/fc42bbccb9041fafd194fbfdf3eab1d44cb5c45c";>fc42bbcc. + +The issue was made public on 10 July 2025. + +Affects: 10.1.0-M1 to 10.1.42 + +Important: DoS via excessive HTTP/2 streams + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-53506"; rel="nofollow">CVE-2025-53506 + +An uncontrolled resource consumption vulnerability if an HTTP/2 client + did not acknowledge the initial settings frame that reduces the maximum + permitted concurrent streams could result in a DoS. + +This was fixed with commit + https://github.com/apache/tomcat/commit/2aa6261276ebe50b99276953591e3a2be7898bdb";>2aa62612. + +The issue was made public on 10 July 2025. + +Affects: 10.1.0-M1 to 10.1.42 + 2025-06-09 Fixed in Apache Tomcat 10.1.42 Moderate: Security constraint bypass for PreResources and Modified: tomcat/site/trunk/docs/security-11.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-11.html?rev=1927120&r1=1927119&r2=1927120&view=diff == --- tomcat/site/trunk/docs/security-11.html (original) +++ tomcat/site/trunk/docs/security-11.html Thu Jul 10 18:55:09 2025 @@ -36,7 +36,36 @@ Table of Contents -Fixed in Apache Tomcat 11.0.8Fixed in Apache Tomcat 11.0.7Fixed in Apache Tomcat 11.0.6Fixed in Apache Tomcat 11.0.3Fixed in Apache Tomcat 11.0.2Fixed in Apache Tomcat 11.0.1Fixed in Apache Tomcat 11.0.0Fixed in Apache Tomcat 11.0.0-M21Fixed in Apache Tomcat 11.0.0-M17Fixed in Apache Tomcat 11.0.0-M12Fi
[SECURITY] CVE-2025-52520 Apache Tomcat - DoS in multipart upload
CVE-2025-52520 Apache Tomcat - DoS in multipart upload Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.8 Apache Tomcat 10.1.0-M1 to 10.1.42 Apache Tomcat 9.0.0.M1 to 9.0.106 Description: For some unlikely configurations of multipart upload, an Integer Overflow vulnerability could lead to a DoS via bypassing of size limits. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.9 or later - Upgrade to Apache Tomcat 10.1.32 or later - Upgrade to Apache Tomcat 9.0.107 or later Credit: The vulnerability was identified by Saravana Kumar History: 2025-07-10 Original advisory References: [1] https://tomcat.apache.org/security-11.html [2] https://tomcat.apache.org/security-10.html [3] https://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2025-53506 Apache Tomcat - DoS in HTP/2
Correcting typo in fixed versions CVE-2025-53506 Apache Tomcat - DoS in HTTP/2 Severity: High Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.8 Apache Tomcat 10.1.0-M1 to 10.1.42 Apache Tomcat 9.0.0.M1 to 9.0.106 Description: An uncontrolled resource consumption vulnerability if an HTTP/2 client did not acknowledge the initial settings frame that reduces the maximum permitted concurrent streams could result in a DoS. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.9 or later - Upgrade to Apache Tomcat 10.1.43 or later - Upgrade to Apache Tomcat 9.0.107 or later Credit: The vulnerability was identified by Kanatoko History: 2025-07-10 Original advisory 2025-07-10 Correction to fixed versions References: [1] https://tomcat.apache.org/security-11.html [2] https://tomcat.apache.org/security-10.html [3] https://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2025-52520 Apache Tomcat - DoS in multipart upload
Correcting typo in fixed versions CVE-2025-52520 Apache Tomcat - DoS in multipart upload Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.8 Apache Tomcat 10.1.0-M1 to 10.1.42 Apache Tomcat 9.0.0.M1 to 9.0.106 Description: For some unlikely configurations of multipart upload, an Integer Overflow vulnerability could lead to a DoS via bypassing of size limits. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.9 or later - Upgrade to Apache Tomcat 10.1.43 or later - Upgrade to Apache Tomcat 9.0.107 or later Credit: The vulnerability was identified by Saravana Kumar History: 2025-07-10 Original advisory 2025-07-10 Correction to fixed versions References: [1] https://tomcat.apache.org/security-11.html [2] https://tomcat.apache.org/security-10.html [3] https://tomcat.apache.org/security-9.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
