[Bug 69447] Tomcat 9.0.97 fails to load classes due to the newly added ConcurrentLruCache
https://bz.apache.org/bugzilla/show_bug.cgi?id=69447 --- Comment #5 from Conrad Kostecki --- I can also confirm, that the workaround works fine for 9.0.97. Thanks! -- 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
(tomcat) branch main updated: Fix BZ 69466 - rework handling of HEAD requests
This is an automated email from the ASF dual-hosted git repository.
markt 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 a7fff9cfb1 Fix BZ 69466 - rework handling of HEAD requests
a7fff9cfb1 is described below
commit a7fff9cfb1bb02dc5aaf1ddc518bc74d2313302d
Author: Mark Thomas
AuthorDate: Thu Nov 21 16:14:49 2024 +
Fix BZ 69466 - rework handling of HEAD requests
Headers explicitly set by users will not be removed and any header
present in a HEAD request will also be present in the equivalent GET
request. There may be some headers, as per RFC 9110, section 9.3.2, that
are present in a GET request that are not present in the equivalent HEAD
request.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69466
---
.../apache/catalina/connector/OutputBuffer.java| 11 +-
java/org/apache/coyote/http11/Http11Processor.java | 18 +-
java/org/apache/coyote/http2/StreamProcessor.java | 7 -
.../servlet/http/HttpServletDoHeadBaseTest.java| 113 +++--
test/jakarta/servlet/http/TestHttpServlet.java | 37 ++---
test/jakarta/servlet/http/TesterConstants.java | 23 +++
.../coyote/http11/TestHttp11ProcessorDoHead.java | 182 +
webapps/docs/changelog.xml | 7 +
8 files changed, 302 insertions(+), 96 deletions(-)
diff --git a/java/org/apache/catalina/connector/OutputBuffer.java
b/java/org/apache/catalina/connector/OutputBuffer.java
index 04cf82e632..a1adae91aa 100644
--- a/java/org/apache/catalina/connector/OutputBuffer.java
+++ b/java/org/apache/catalina/connector/OutputBuffer.java
@@ -220,9 +220,14 @@ public class OutputBuffer extends Writer {
flushCharBuffer();
}
-if ((!coyoteResponse.isCommitted()) &&
(coyoteResponse.getContentLengthLong() == -1)) {
-// If this didn't cause a commit of the response, the final content
-// length can be calculated.
+// Content length can be calculated if:
+// - the response has not been committed
+// AND
+// - the content length has not been explicitly set
+// AND
+// - some content has been written OR this is NOT a HEAD request
+if ((!coyoteResponse.isCommitted()) &&
(coyoteResponse.getContentLengthLong() == -1) &&
+((bb.remaining() > 0 ||
!coyoteResponse.getRequest().method().equals("HEAD" {
coyoteResponse.setContentLength(bb.remaining());
}
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index 53b38d8c57..afdef54424 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -895,7 +895,7 @@ public class Http11Processor extends AbstractProcessor {
boolean head = request.method().equals("HEAD");
if (head) {
-// No entity body
+// Any entity body, if present, should not be sent
outputBuffer.addActiveFilter(outputFilters[Constants.VOID_FILTER]);
contentDelimitation = true;
}
@@ -935,6 +935,13 @@ public class Http11Processor extends AbstractProcessor {
headers.setValue("Content-Length").setLong(contentLength);
outputBuffer.addActiveFilter(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
+} else if (head) {
+/*
+ * The OutputBuffer can't differentiate between a zero length
response because GET would have produced a
+ * zero length body and a zero length response because HEAD didn't
write any content. Therefore skip setting
+ * the "transfer-encoding: chunked" header as that may not be
consistent with what would be seen with the
+ * equivalent GET.
+ */
} else {
// If the response code supports an entity body and we're on
// HTTP 1.1 then we chunk unless we have a Connection: close header
@@ -1034,15 +1041,6 @@ public class Http11Processor extends AbstractProcessor {
headers.setValue("Server").setString(server);
}
-// Exclude some HTTP header fields where the value is determined only
-// while generating the content as per section 9.3.2 of RFC 9110.
-if (head) {
-headers.removeHeader("content-length");
-headers.removeHeader("content-range");
-headers.removeHeader("trailer");
-headers.removeHeader("transfer-encoding");
-}
-
writeHeaders(response.getStatus(), headers);
outputBuffer.commit();
diff --git a/java/org/apache/coyote/http2/StreamProcessor.java
b/java/org/apache/coyote/http2/StreamProcessor.java
index daac6059b6..a853a5dd8e 100644
--- a/java/org/apache/coyote/http2/StreamProcessor.j
Re: Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42
чт, 21 лист. 2024 р. о 16:47 Rémy Maucherat пише: > On Thu, Nov 21, 2024 at 4:33 PM robot carver > wrote: > > > > Hi! > > I am posting this into the dev list as I am not familiar with the right > > place for a DBCP issue in Tomcat's Bugzilla structure. > > > > I am seeking Rémy attention, as he is currently maintaining Tomcat 9. > > > > Could you please review this DBCP2 issue? > > > > I think Tomcat 9 has an issue with closing the abandoned connections (if > > configured) since Tomcat 9.0.42: > > "Update the internal fork of Apache Commons DBCP to 2.9.0 (2021-08-03). > > Improvements, code clean-up and refactoring. (markt)" > > > > https://issues.apache.org/jira/browse/DBCP-599 > > > > The cool thing about this issue is that other Tomcat versions are also > > affected, as I understand. > > 2.12.0 is the latest commons-dbcp release. Yep, the mentioned issue is true also for DBCP 2.12.0. I understand this issue is > important to you, but reading it, it seems to need a very ancient DBCP > driver to run into that. Maybe you should look into updating that > first ? > I understand the statement about "you have a JDBC 4.0 driver and it is the cause for this Error", but what I try to convey: as I know, tomcat has no limits for the jdbc version. I meant there is no "must use JDBC 4.2 or more recent" requirement from Tomcat side. Also, a one-liner fix proposed by Gary Gregory repairs the issue with Error thrown in a specific place, where this issue is present, while keeping the absence of requirement for JDBC 4.2, you could use the JDBC 4.0 driver and be safe with your connection pool to be maintained. Anton. > > Rémy > > > Thank you! > > Anton. > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
[Bug 69447] Tomcat 9.0.97 fails to load classes due to the newly added ConcurrentLruCache
https://bz.apache.org/bugzilla/show_bug.cgi?id=69447 --- Comment #4 from so...@his.de --- Thank you :) I will test your patch when tomcat 9.0.98 is released. -- 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
(tomcat) branch 11.0.x updated: Add two missing strings
This is an automated email from the ASF dual-hosted git repository.
remm 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 9a75e435d6 Add two missing strings
9a75e435d6 is described below
commit 9a75e435d6f6a45db333a41f968f27cdd9e5f181
Author: remm
AuthorDate: Thu Nov 21 10:52:15 2024 +0100
Add two missing strings
---
java/org/apache/catalina/servlets/DefaultServlet.java | 4 ++--
java/org/apache/catalina/servlets/LocalStrings.properties | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/java/org/apache/catalina/servlets/DefaultServlet.java
b/java/org/apache/catalina/servlets/DefaultServlet.java
index 26a3a1daea..d416784f80 100644
--- a/java/org/apache/catalina/servlets/DefaultServlet.java
+++ b/java/org/apache/catalina/servlets/DefaultServlet.java
@@ -302,7 +302,7 @@ public class DefaultServlet extends HttpServlet {
directoryRedirectStatusCode = statusCode;
break;
default:
-log("Invalid redirectStatusCode of " + statusCode);
+
log(sm.getString("defaultServlet.invalidRedirectStatusCode",
Integer.valueOf(statusCode)));
}
}
@@ -1960,7 +1960,7 @@ public class DefaultServlet extends HttpServlet {
if (f != null) {
long globalXsltFileSize = f.length();
if (globalXsltFileSize > Integer.MAX_VALUE) {
-log("globalXsltFile [" + f.getAbsolutePath() + "] is too
big to buffer");
+log(sm.getString("defaultServlet.globalXSLTTooBig",
f.getAbsolutePath()));
} else {
try (FileInputStream fis = new FileInputStream(f)) {
byte b[] = new byte[(int) f.length()];
diff --git a/java/org/apache/catalina/servlets/LocalStrings.properties
b/java/org/apache/catalina/servlets/LocalStrings.properties
index 00a830f4c0..ed67a34049 100644
--- a/java/org/apache/catalina/servlets/LocalStrings.properties
+++ b/java/org/apache/catalina/servlets/LocalStrings.properties
@@ -42,6 +42,8 @@ defaultServlet.blockExternalEntity2=Blocked access to
external entity with name
defaultServlet.blockExternalSubset=Blocked access to external subset with name
[{0}] and baseURI [{1}]
defaultServlet.directory.parent=Up To [{0}]
defaultServlet.directory.title=Directory Listing For [{0}]
+defaultServlet.globalXSLTTooBig=The global XSLT file [{0}] is too big to buffer
+defaultServlet.invalidRedirectStatusCode=Invalid redirect status code [{0}]
defaultServlet.missingResource=The requested resource [{0}] is not available
defaultServlet.noResources=No static resources were found
defaultServlet.readerCloseFailed=Failed to close reader
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Add two missing strings
This is an automated email from the ASF dual-hosted git repository.
remm 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 5f0888afba Add two missing strings
5f0888afba is described below
commit 5f0888afba0759c7eb7e1459aa2f3de4f99f0d33
Author: remm
AuthorDate: Thu Nov 21 10:52:15 2024 +0100
Add two missing strings
---
java/org/apache/catalina/servlets/DefaultServlet.java | 4 ++--
java/org/apache/catalina/servlets/LocalStrings.properties | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/java/org/apache/catalina/servlets/DefaultServlet.java
b/java/org/apache/catalina/servlets/DefaultServlet.java
index 26a3a1daea..d416784f80 100644
--- a/java/org/apache/catalina/servlets/DefaultServlet.java
+++ b/java/org/apache/catalina/servlets/DefaultServlet.java
@@ -302,7 +302,7 @@ public class DefaultServlet extends HttpServlet {
directoryRedirectStatusCode = statusCode;
break;
default:
-log("Invalid redirectStatusCode of " + statusCode);
+
log(sm.getString("defaultServlet.invalidRedirectStatusCode",
Integer.valueOf(statusCode)));
}
}
@@ -1960,7 +1960,7 @@ public class DefaultServlet extends HttpServlet {
if (f != null) {
long globalXsltFileSize = f.length();
if (globalXsltFileSize > Integer.MAX_VALUE) {
-log("globalXsltFile [" + f.getAbsolutePath() + "] is too
big to buffer");
+log(sm.getString("defaultServlet.globalXSLTTooBig",
f.getAbsolutePath()));
} else {
try (FileInputStream fis = new FileInputStream(f)) {
byte b[] = new byte[(int) f.length()];
diff --git a/java/org/apache/catalina/servlets/LocalStrings.properties
b/java/org/apache/catalina/servlets/LocalStrings.properties
index 00a830f4c0..ed67a34049 100644
--- a/java/org/apache/catalina/servlets/LocalStrings.properties
+++ b/java/org/apache/catalina/servlets/LocalStrings.properties
@@ -42,6 +42,8 @@ defaultServlet.blockExternalEntity2=Blocked access to
external entity with name
defaultServlet.blockExternalSubset=Blocked access to external subset with name
[{0}] and baseURI [{1}]
defaultServlet.directory.parent=Up To [{0}]
defaultServlet.directory.title=Directory Listing For [{0}]
+defaultServlet.globalXSLTTooBig=The global XSLT file [{0}] is too big to buffer
+defaultServlet.invalidRedirectStatusCode=Invalid redirect status code [{0}]
defaultServlet.missingResource=The requested resource [{0}] is not available
defaultServlet.noResources=No static resources were found
defaultServlet.readerCloseFailed=Failed to close reader
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Improve status manager information
This is an automated email from the ASF dual-hosted git repository. remm 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 06148126e5 Improve status manager information 06148126e5 is described below commit 06148126e5d227e6589f5a19b297d867c790742c Author: remm AuthorDate: Thu Nov 21 10:16:44 2024 +0100 Improve status manager information --- webapps/docs/manager-howto.xml | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/webapps/docs/manager-howto.xml b/webapps/docs/manager-howto.xml index f9678f415e..e90a35e52a 100644 --- a/webapps/docs/manager-howto.xml +++ b/webapps/docs/manager-howto.xml @@ -1043,22 +1043,27 @@ href="config/listeners.html#StoreConfig_Lifecycle_Listener_-_org.apache.catalina From the following links you can view Status information about the server. -Any one of manager-xxx roles allows access to this page. +The manager-status role or any one of the other +manager-xxx roles allow access to this page. http://localhost:8080/manager/status http://localhost:8080/manager/status/all Displays server status information in HTML format. -http://localhost:8080/manager/status?XML=true -http://localhost:8080/manager/status/all?XML=true +http://localhost:8080/manager/status?XML=true -Displays server status information in XML format. +Displays server status information in XML format. The XML format does +not include the detailed per web application statistics. http://localhost:8080/manager/status?JSON=true http://localhost:8080/manager/status/all?JSON=true -Displays server status information in JSON format. +Displays server status information in JSON format. The JSON format does +not include the per thread state information. If using a client visualization +tool for active monitoring and server status alerts (such as Grafana), the JSON +output provided by the Manager will likely provide the easiest and most secure +solution. First, you have the server and JVM version number, JVM provider, OS name and number followed by the architecture type. @@ -1073,8 +1078,9 @@ The same information is available for both of them : current thread count and current thread busy. Request information : Max processing time and processing time, request and error count, bytes received and sent. -A table showing Stage, Time, Bytes Sent, Bytes Receive, Client, -VHost and Request. All existing threads are listed in the table. +If not using the JSON format, the state of threads with Stage, +Time, Bytes Sent, Bytes Receive, Client, VHost and Request. +All existing threads are listed in the table. Here is the list of the possible thread stages : "Parse and Prepare Request" : The request headers are @@ -1101,7 +1107,8 @@ The same information is available for both of them : If you are using /status/all command, additional information -on each of deployed web applications will be available. +on each of deployed web applications will be available, except for the XML +format. - 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: Improve status manager information
This is an automated email from the ASF dual-hosted git repository. remm 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 d0a80ec2ee Improve status manager information d0a80ec2ee is described below commit d0a80ec2ee5e5e93a77885e5e0469c1bbd322ba1 Author: remm AuthorDate: Thu Nov 21 10:16:44 2024 +0100 Improve status manager information --- webapps/docs/manager-howto.xml | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/webapps/docs/manager-howto.xml b/webapps/docs/manager-howto.xml index 54d5f4d7f0..f9ede9ddab 100644 --- a/webapps/docs/manager-howto.xml +++ b/webapps/docs/manager-howto.xml @@ -1044,22 +1044,27 @@ href="config/listeners.html#StoreConfig_Lifecycle_Listener_-_org.apache.catalina From the following links you can view Status information about the server. -Any one of manager-xxx roles allows access to this page. +The manager-status role or any one of the other +manager-xxx roles allow access to this page. http://localhost:8080/manager/status http://localhost:8080/manager/status/all Displays server status information in HTML format. -http://localhost:8080/manager/status?XML=true -http://localhost:8080/manager/status/all?XML=true +http://localhost:8080/manager/status?XML=true -Displays server status information in XML format. +Displays server status information in XML format. The XML format does +not include the detailed per web application statistics. http://localhost:8080/manager/status?JSON=true http://localhost:8080/manager/status/all?JSON=true -Displays server status information in JSON format. +Displays server status information in JSON format. The JSON format does +not include the per thread state information. If using a client visualization +tool for active monitoring and server status alerts (such as Grafana), the JSON +output provided by the Manager will likely provide the easiest and most secure +solution. First, you have the server and JVM version number, JVM provider, OS name and number followed by the architecture type. @@ -1074,8 +1079,9 @@ The same information is available for both of them : current thread count and current thread busy. Request information : Max processing time and processing time, request and error count, bytes received and sent. -A table showing Stage, Time, Bytes Sent, Bytes Receive, Client, -VHost and Request. All existing threads are listed in the table. +If not using the JSON format, the state of threads with Stage, +Time, Bytes Sent, Bytes Receive, Client, VHost and Request. +All existing threads are listed in the table. Here is the list of the possible thread stages : "Parse and Prepare Request" : The request headers are @@ -1102,7 +1108,8 @@ The same information is available for both of them : If you are using /status/all command, additional information -on each of deployed web applications will be available. +on each of deployed web applications will be available, except for the XML +format. - 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: Improve status manager information
This is an automated email from the ASF dual-hosted git repository. remm 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 a4ee31b031 Improve status manager information a4ee31b031 is described below commit a4ee31b0313f784c4f5093b8f01f11682ba5416d Author: remm AuthorDate: Thu Nov 21 10:16:44 2024 +0100 Improve status manager information --- webapps/docs/manager-howto.xml | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/webapps/docs/manager-howto.xml b/webapps/docs/manager-howto.xml index f9678f415e..e90a35e52a 100644 --- a/webapps/docs/manager-howto.xml +++ b/webapps/docs/manager-howto.xml @@ -1043,22 +1043,27 @@ href="config/listeners.html#StoreConfig_Lifecycle_Listener_-_org.apache.catalina From the following links you can view Status information about the server. -Any one of manager-xxx roles allows access to this page. +The manager-status role or any one of the other +manager-xxx roles allow access to this page. http://localhost:8080/manager/status http://localhost:8080/manager/status/all Displays server status information in HTML format. -http://localhost:8080/manager/status?XML=true -http://localhost:8080/manager/status/all?XML=true +http://localhost:8080/manager/status?XML=true -Displays server status information in XML format. +Displays server status information in XML format. The XML format does +not include the detailed per web application statistics. http://localhost:8080/manager/status?JSON=true http://localhost:8080/manager/status/all?JSON=true -Displays server status information in JSON format. +Displays server status information in JSON format. The JSON format does +not include the per thread state information. If using a client visualization +tool for active monitoring and server status alerts (such as Grafana), the JSON +output provided by the Manager will likely provide the easiest and most secure +solution. First, you have the server and JVM version number, JVM provider, OS name and number followed by the architecture type. @@ -1073,8 +1078,9 @@ The same information is available for both of them : current thread count and current thread busy. Request information : Max processing time and processing time, request and error count, bytes received and sent. -A table showing Stage, Time, Bytes Sent, Bytes Receive, Client, -VHost and Request. All existing threads are listed in the table. +If not using the JSON format, the state of threads with Stage, +Time, Bytes Sent, Bytes Receive, Client, VHost and Request. +All existing threads are listed in the table. Here is the list of the possible thread stages : "Parse and Prepare Request" : The request headers are @@ -1101,7 +1107,8 @@ The same information is available for both of them : If you are using /status/all command, additional information -on each of deployed web applications will be available. +on each of deployed web applications will be available, except for the XML +format. - 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: Improve status manager information
This is an automated email from the ASF dual-hosted git repository. remm 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 c24cace8c9 Improve status manager information c24cace8c9 is described below commit c24cace8c9dc71851e38c450c9ce681ea422149e Author: remm AuthorDate: Thu Nov 21 10:16:44 2024 +0100 Improve status manager information --- webapps/docs/manager-howto.xml | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/webapps/docs/manager-howto.xml b/webapps/docs/manager-howto.xml index f9678f415e..e90a35e52a 100644 --- a/webapps/docs/manager-howto.xml +++ b/webapps/docs/manager-howto.xml @@ -1043,22 +1043,27 @@ href="config/listeners.html#StoreConfig_Lifecycle_Listener_-_org.apache.catalina From the following links you can view Status information about the server. -Any one of manager-xxx roles allows access to this page. +The manager-status role or any one of the other +manager-xxx roles allow access to this page. http://localhost:8080/manager/status http://localhost:8080/manager/status/all Displays server status information in HTML format. -http://localhost:8080/manager/status?XML=true -http://localhost:8080/manager/status/all?XML=true +http://localhost:8080/manager/status?XML=true -Displays server status information in XML format. +Displays server status information in XML format. The XML format does +not include the detailed per web application statistics. http://localhost:8080/manager/status?JSON=true http://localhost:8080/manager/status/all?JSON=true -Displays server status information in JSON format. +Displays server status information in JSON format. The JSON format does +not include the per thread state information. If using a client visualization +tool for active monitoring and server status alerts (such as Grafana), the JSON +output provided by the Manager will likely provide the easiest and most secure +solution. First, you have the server and JVM version number, JVM provider, OS name and number followed by the architecture type. @@ -1073,8 +1078,9 @@ The same information is available for both of them : current thread count and current thread busy. Request information : Max processing time and processing time, request and error count, bytes received and sent. -A table showing Stage, Time, Bytes Sent, Bytes Receive, Client, -VHost and Request. All existing threads are listed in the table. +If not using the JSON format, the state of threads with Stage, +Time, Bytes Sent, Bytes Receive, Client, VHost and Request. +All existing threads are listed in the table. Here is the list of the possible thread stages : "Parse and Prepare Request" : The request headers are @@ -1101,7 +1107,8 @@ The same information is available for both of them : If you are using /status/all command, additional information -on each of deployed web applications will be available. +on each of deployed web applications will be available, except for the XML +format. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69466] Content-Length removal from HEAD response should not be mandatory
https://bz.apache.org/bugzilla/show_bug.cgi?id=69466 Remy Maucherat changed: What|Removed |Added CC||pawel.vese...@gmail.com --- Comment #1 from Remy Maucherat --- *** Bug 69469 has been marked as a duplicate of this bug. *** -- 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 69468] Uploaded file is corrupted when using HTTP 2 and JSSE
https://bz.apache.org/bugzilla/show_bug.cgi?id=69468 --- Comment #2 from Mark Thomas --- Thanks for letting us know. -- 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 69466] Content-Length removal from HEAD response should not be mandatory
https://bz.apache.org/bugzilla/show_bug.cgi?id=69466 --- Comment #2 from Mark Thomas --- For info, I am working on a better fix for this at the moment. We have an extensive set of tests (about 18,000) for this that cover all sorts of edge cases. The approach I am trying to implement is: - don't remove any user set headers from a HEAD - any header (excluding Date) present in HEAD must be the same for GET - content related headers referenced in RFC 9110, section 9.3.2 that are present in GET but not the equivalent HEAD are allowed -- 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 69466] Content-Length removal from HEAD response should not be mandatory
https://bz.apache.org/bugzilla/show_bug.cgi?id=69466 --- Comment #3 from Pawel Veselov --- @Mark - regarding implementation - may be marking a response as "not handled directly" by a servlet, i.e., handled through default implementation of HttpServlet.doHead(), applying the current filters to such marked requests, and then making it servlet's responsibility to set the headers correctly? Otherwise, there may be servlets that set, say, content-length header in doGet(), but will produce dynamic/generated data, so two consecutive requests to HEAD and GET will produce different header values. And if a servlet does do its own doHead(), and messed the headers up, it's not the container's fault. The predicament here is also that: a) if somebody depends on having content-length in HEAD, they are rather blocked from using 10.1.32 and up b) CVE-2024-52316 precludes use of anything below 10.1.31 c) CVE-2024-52318 precludes use of 10.1.31 (in favor of at least 10.1.32) -- 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
Re: Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42
On Thu, Nov 21, 2024 at 4:33 PM robot carver wrote: > > Hi! > I am posting this into the dev list as I am not familiar with the right > place for a DBCP issue in Tomcat's Bugzilla structure. > > I am seeking Rémy attention, as he is currently maintaining Tomcat 9. > > Could you please review this DBCP2 issue? > > I think Tomcat 9 has an issue with closing the abandoned connections (if > configured) since Tomcat 9.0.42: > "Update the internal fork of Apache Commons DBCP to 2.9.0 (2021-08-03). > Improvements, code clean-up and refactoring. (markt)" > > https://issues.apache.org/jira/browse/DBCP-599 > > The cool thing about this issue is that other Tomcat versions are also > affected, as I understand. 2.12.0 is the latest commons-dbcp release. I understand this issue is important to you, but reading it, it seems to need a very ancient DBCP driver to run into that. Maybe you should look into updating that first ? Rémy > Thank you! > Anton. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69468] Uploaded file is corrupted when using HTTP 2 and JSSE
https://bz.apache.org/bugzilla/show_bug.cgi?id=69468 Christopher Schultz changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #3 from Christopher Schultz --- Slightly changing resolution. -- 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
Re: Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42
Rémy, On 11/21/24 10:46 AM, Rémy Maucherat wrote: On Thu, Nov 21, 2024 at 4:33 PM robot carver wrote: Hi! I am posting this into the dev list as I am not familiar with the right place for a DBCP issue in Tomcat's Bugzilla structure. I am seeking Rémy attention, as he is currently maintaining Tomcat 9. Could you please review this DBCP2 issue? I think Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42: "Update the internal fork of Apache Commons DBCP to 2.9.0 (2021-08-03). Improvements, code clean-up and refactoring. (markt)" https://issues.apache.org/jira/browse/DBCP-599 The cool thing about this issue is that other Tomcat versions are also affected, as I understand. 2.12.0 is the latest commons-dbcp release. I understand this issue is important to you, but reading it, it seems to need a very ancient DBCP driver to run into that. s/DBCP/JDBC/ Maybe you should look into updating that first? +1 -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Allow applications to trigger sending of 103 early hints [tomcat]
ChristopherSchultz commented on PR #764: URL: https://github.com/apache/tomcat/pull/764#issuecomment-2491096139 The Servlet 6.2 spec doesn't actually exist yet... at least not in any published form. That reference is speculative, assuming that the work being done here will ultimately be released as Servlet 6.2: https://github.com/jakartaee/servlet/tree/master/spec -- 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
[Bug 69468] Uploaded file is corrupted when using HTTP 2 and JSSE
https://bz.apache.org/bugzilla/show_bug.cgi?id=69468 Jiri Trnka changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED OS||All --- Comment #1 from Jiri Trnka --- After some digging we found the problem is our antivirus SW. https://support.eset.com/en/kb3126-disable-ssl-filtering-in-eset-windows-products -- 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 69469] New: Servlets can not set certain headers in responses to HEAD requests
https://bz.apache.org/bugzilla/show_bug.cgi?id=69469
Bug ID: 69469
Summary: Servlets can not set certain headers in responses to
HEAD requests
Product: Tomcat 10
Version: 10.1.33
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: pawel.vese...@gmail.com
Target Milestone: --
Caused by changes for https://bz.apache.org/bugzilla/show_bug.cgi?id=69379.
The change forces certain headers out of the responses:
headers.remove("content-length");
headers.remove("content-range");
headers.remove("trailer");
headers.remove("transfer-encoding");
So, even if a servlet wants to set the "content-length" header (others are
probably never useful for a HEAD response), the set header doesn't show up in
the response.
Note that the FIX notes for 69379 are:
69379: The default HEAD response no longer includes the
payload HTTP header fields as per section 9.3.2 of RFC 9110. (markt)
However, the result of the fix is that even the non-default HEAD response can't
have those headers.
To reproduce, have a servlet class that overrides `doHead()`, and call
response.setHeader("Content-length", String.valueOf(contentLength));
--
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 69469] Servlets can not set certain headers in responses to HEAD requests
https://bz.apache.org/bugzilla/show_bug.cgi?id=69469 Remy Maucherat changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Remy Maucherat --- *** This bug has been marked as a duplicate of bug 69466 *** -- 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 69444] jakarta.servlet.error.message request attribute should be empty string instead of null
https://bz.apache.org/bugzilla/show_bug.cgi?id=69444 --- Comment #7 from Paolo B. --- Thanks! I've reported this to Mojarra project -- 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
Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42
Hi! I am posting this into the dev list as I am not familiar with the right place for a DBCP issue in Tomcat's Bugzilla structure. I am seeking Rémy attention, as he is currently maintaining Tomcat 9. Could you please review this DBCP2 issue? I think Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42: "Update the internal fork of Apache Commons DBCP to 2.9.0 (2021-08-03). Improvements, code clean-up and refactoring. (markt)" https://issues.apache.org/jira/browse/DBCP-599 The cool thing about this issue is that other Tomcat versions are also affected, as I understand. Thank you! Anton.
(tomcat) branch 11.0.x updated: Fix BZ 69466 - rework handling of HEAD requests
This is an automated email from the ASF dual-hosted git repository.
markt 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 c899ae319d Fix BZ 69466 - rework handling of HEAD requests
c899ae319d is described below
commit c899ae319d0e1c307b648d9affeaf2b622739be3
Author: Mark Thomas
AuthorDate: Thu Nov 21 16:14:49 2024 +
Fix BZ 69466 - rework handling of HEAD requests
Headers explicitly set by users will not be removed and any header
present in a HEAD request will also be present in the equivalent GET
request. There may be some headers, as per RFC 9110, section 9.3.2, that
are present in a GET request that are not present in the equivalent HEAD
request.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69466
---
.../apache/catalina/connector/OutputBuffer.java| 11 +-
java/org/apache/coyote/http11/Http11Processor.java | 18 +-
java/org/apache/coyote/http2/StreamProcessor.java | 7 -
.../servlet/http/HttpServletDoHeadBaseTest.java| 113 +++--
test/jakarta/servlet/http/TestHttpServlet.java | 37 ++---
test/jakarta/servlet/http/TesterConstants.java | 23 +++
.../coyote/http11/TestHttp11ProcessorDoHead.java | 182 +
webapps/docs/changelog.xml | 7 +
8 files changed, 302 insertions(+), 96 deletions(-)
diff --git a/java/org/apache/catalina/connector/OutputBuffer.java
b/java/org/apache/catalina/connector/OutputBuffer.java
index 04cf82e632..a1adae91aa 100644
--- a/java/org/apache/catalina/connector/OutputBuffer.java
+++ b/java/org/apache/catalina/connector/OutputBuffer.java
@@ -220,9 +220,14 @@ public class OutputBuffer extends Writer {
flushCharBuffer();
}
-if ((!coyoteResponse.isCommitted()) &&
(coyoteResponse.getContentLengthLong() == -1)) {
-// If this didn't cause a commit of the response, the final content
-// length can be calculated.
+// Content length can be calculated if:
+// - the response has not been committed
+// AND
+// - the content length has not been explicitly set
+// AND
+// - some content has been written OR this is NOT a HEAD request
+if ((!coyoteResponse.isCommitted()) &&
(coyoteResponse.getContentLengthLong() == -1) &&
+((bb.remaining() > 0 ||
!coyoteResponse.getRequest().method().equals("HEAD" {
coyoteResponse.setContentLength(bb.remaining());
}
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index 53b38d8c57..afdef54424 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -895,7 +895,7 @@ public class Http11Processor extends AbstractProcessor {
boolean head = request.method().equals("HEAD");
if (head) {
-// No entity body
+// Any entity body, if present, should not be sent
outputBuffer.addActiveFilter(outputFilters[Constants.VOID_FILTER]);
contentDelimitation = true;
}
@@ -935,6 +935,13 @@ public class Http11Processor extends AbstractProcessor {
headers.setValue("Content-Length").setLong(contentLength);
outputBuffer.addActiveFilter(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
+} else if (head) {
+/*
+ * The OutputBuffer can't differentiate between a zero length
response because GET would have produced a
+ * zero length body and a zero length response because HEAD didn't
write any content. Therefore skip setting
+ * the "transfer-encoding: chunked" header as that may not be
consistent with what would be seen with the
+ * equivalent GET.
+ */
} else {
// If the response code supports an entity body and we're on
// HTTP 1.1 then we chunk unless we have a Connection: close header
@@ -1034,15 +1041,6 @@ public class Http11Processor extends AbstractProcessor {
headers.setValue("Server").setString(server);
}
-// Exclude some HTTP header fields where the value is determined only
-// while generating the content as per section 9.3.2 of RFC 9110.
-if (head) {
-headers.removeHeader("content-length");
-headers.removeHeader("content-range");
-headers.removeHeader("trailer");
-headers.removeHeader("transfer-encoding");
-}
-
writeHeaders(response.getStatus(), headers);
outputBuffer.commit();
diff --git a/java/org/apache/coyote/http2/StreamProcessor.java
b/java/org/apache/coyote/http2/StreamProcessor.java
index daac6059b6..a853a5dd8e 100644
--- a/java/org/apache/coyote/http2/StreamProcess
Re: Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42
On 21/11/2024 16:19, robot carver wrote: чт, 21 лист. 2024 р. о 16:47 Rémy Maucherat пише: On Thu, Nov 21, 2024 at 4:33 PM robot carver wrote: Hi! I am posting this into the dev list as I am not familiar with the right place for a DBCP issue in Tomcat's Bugzilla structure. I am seeking Rémy attention, as he is currently maintaining Tomcat 9. Could you please review this DBCP2 issue? I think Tomcat 9 has an issue with closing the abandoned connections (if configured) since Tomcat 9.0.42: "Update the internal fork of Apache Commons DBCP to 2.9.0 (2021-08-03). Improvements, code clean-up and refactoring. (markt)" https://issues.apache.org/jira/browse/DBCP-599 The cool thing about this issue is that other Tomcat versions are also affected, as I understand. 2.12.0 is the latest commons-dbcp release. Yep, the mentioned issue is true also for DBCP 2.12.0. I understand this issue is important to you, but reading it, it seems to need a very ancient DBCP driver to run into that. Maybe you should look into updating that first ? I understand the statement about "you have a JDBC 4.0 driver and it is the cause for this Error", but what I try to convey: as I know, tomcat has no limits for the jdbc version. I meant there is no "must use JDBC 4.2 or more recent" requirement from Tomcat side. Also, a one-liner fix proposed by Gary Gregory repairs the issue with Error thrown in a specific place, where this issue is present, while keeping the absence of requirement for JDBC 4.2, you could use the JDBC 4.0 driver and be safe with your connection pool to be maintained. And when Commons DBCP applies that fix and makes a release we will pick it up. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 69466] Content-Length removal from HEAD response should not be mandatory
https://bz.apache.org/bugzilla/show_bug.cgi?id=69466 --- Comment #4 from Mark Thomas --- If you need a work-around until the December releases, use 10.1.31 and disable tag pooling. -- 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
(tomcat) branch 10.1.x updated: Fix BZ 69466 - rework handling of HEAD requests
This is an automated email from the ASF dual-hosted git repository.
markt 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 8847b6638b Fix BZ 69466 - rework handling of HEAD requests
8847b6638b is described below
commit 8847b6638bece78c47186c5fed15d17e835b1d9e
Author: Mark Thomas
AuthorDate: Thu Nov 21 16:14:49 2024 +
Fix BZ 69466 - rework handling of HEAD requests
Headers explicitly set by users will not be removed and any header
present in a HEAD request will also be present in the equivalent GET
request. There may be some headers, as per RFC 9110, section 9.3.2, that
are present in a GET request that are not present in the equivalent HEAD
request.
https://bz.apache.org/bugzilla/show_bug.cgi?id=69466
---
.../apache/catalina/connector/OutputBuffer.java| 11 +-
java/org/apache/coyote/http11/Http11Processor.java | 16 +-
java/org/apache/coyote/http2/StreamProcessor.java | 6 -
.../servlet/http/HttpServletDoHeadBaseTest.java| 121 +++---
test/jakarta/servlet/http/TestHttpServlet.java | 37 ++---
test/jakarta/servlet/http/TesterConstants.java | 23 +++
.../coyote/http11/TestHttp11ProcessorDoHead.java | 182 +
webapps/docs/changelog.xml | 7 +
8 files changed, 306 insertions(+), 97 deletions(-)
diff --git a/java/org/apache/catalina/connector/OutputBuffer.java
b/java/org/apache/catalina/connector/OutputBuffer.java
index ede9343c65..c0a9d77315 100644
--- a/java/org/apache/catalina/connector/OutputBuffer.java
+++ b/java/org/apache/catalina/connector/OutputBuffer.java
@@ -232,9 +232,14 @@ public class OutputBuffer extends Writer {
flushCharBuffer();
}
-if ((!coyoteResponse.isCommitted()) &&
(coyoteResponse.getContentLengthLong() == -1)) {
-// If this didn't cause a commit of the response, the final content
-// length can be calculated.
+// Content length can be calculated if:
+// - the response has not been committed
+// AND
+// - the content length has not been explicitly set
+// AND
+// - some content has been written OR this is NOT a HEAD request
+if ((!coyoteResponse.isCommitted()) &&
(coyoteResponse.getContentLengthLong() == -1) &&
+((bb.remaining() > 0 ||
!coyoteResponse.getRequest().method().equals("HEAD" {
coyoteResponse.setContentLength(bb.remaining());
}
diff --git a/java/org/apache/coyote/http11/Http11Processor.java
b/java/org/apache/coyote/http11/Http11Processor.java
index c6df8f5798..44d0894036 100644
--- a/java/org/apache/coyote/http11/Http11Processor.java
+++ b/java/org/apache/coyote/http11/Http11Processor.java
@@ -908,7 +908,7 @@ public class Http11Processor extends AbstractProcessor {
MessageBytes methodMB = request.method();
boolean head = methodMB.equals("HEAD");
if (head) {
-// No entity body
+// Any entity body, if present, should not be sent
outputBuffer.addActiveFilter(outputFilters[Constants.VOID_FILTER]);
contentDelimitation = true;
}
@@ -948,6 +948,13 @@ public class Http11Processor extends AbstractProcessor {
headers.setValue("Content-Length").setLong(contentLength);
outputBuffer.addActiveFilter(outputFilters[Constants.IDENTITY_FILTER]);
contentDelimitation = true;
+} else if (head) {
+/*
+ * The OutputBuffer can't differentiate between a zero length
response because GET would have produced a
+ * zero length body and a zero length response because HEAD didn't
write any content. Therefore skip setting
+ * the "transfer-encoding: chunked" header as that may not be
consistent with what would be seen with the
+ * equivalent GET.
+ */
} else {
// If the response code supports an entity body and we're on
// HTTP 1.1 then we chunk unless we have a Connection: close header
@@ -1047,13 +1054,6 @@ public class Http11Processor extends AbstractProcessor {
headers.setValue("Server").setString(server);
}
-if (head) {
-headers.removeHeader("content-length");
-headers.removeHeader("content-range");
-headers.removeHeader("trailer");
-headers.removeHeader("transfer-encoding");
-}
-
writeHeaders(response.getStatus(), headers);
outputBuffer.commit();
diff --git a/java/org/apache/coyote/http2/StreamProcessor.java
b/java/org/apache/coyote/http2/StreamProcessor.java
index 3d07567b3c..caa3debea3 100644
--- a/java/org/apache/coyote/http2/StreamProcessor.java
+++ b/java/org/apache/coyote/http2/StreamProcessor.java
@@ -255,12 +255,6 @@ class StreamProcessor exten
