Re: Requesting as I had been agreed to commit from a contributor role
> HI Tomcat PMC, > > Please ensure I had showing my interest as a committer as I have been > passed my contribution status from a range of having said that few > contributions > > regards, > Koteswararao >
[SECURITY] CVE-2024-23672 Apache Tomcat - Denial of Service
CVE-2024-23672 Apache Tomcat - Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.0-M16 Apache Tomcat 10.1.0-M1 to 10.1.18 Apache Tomcat 9.0.0-M1 to 9.0.85 Apache Tomcat 8.5.0 to 8.5.98 Description: It was possible for a WebSocket client to keep a WebSocket connection open leading to increased resource consumption. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.0-M17 or later - Upgrade to Apache Tomcat 10.1.19 or later - Upgrade to Apache Tomcat 9.0.86 or later - Upgrade to Apache Tomcat 8.5.99 or later History: 2024-03-13 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 [4] https://tomcat.apache.org/security-8.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[SECURITY] CVE-2024-24549 Apache Tomcat - Denial of Service
CVE-2024-24549 Apache Tomcat - Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 11.0.0-M1 to 11.0.0-M16 Apache Tomcat 10.1.0-M1 to 10.1.18 Apache Tomcat 9.0.0-M1 to 9.0.85 Apache Tomcat 8.5.0 to 8.5.98 Description: When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 11.0.0-M17 or later - Upgrade to Apache Tomcat 10.1.19 or later - Upgrade to Apache Tomcat 9.0.86 or later - Upgrade to Apache Tomcat 8.5.99 or later Credit: This vulnerability was reported responsibly to the Tomcat security team by Bartek Nowotarski (https://nowotarski.info/). History: 2024-03-13 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 [4] https://tomcat.apache.org/security-8.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1916277 - in /tomcat/site/trunk: docs/security-10.html docs/security-11.html docs/security-8.html docs/security-9.html xdocs/security-10.xml xdocs/security-11.xml xdocs/security-8.xml xdo
Author: markt Date: Wed Mar 13 15:41:32 2024 New Revision: 1916277 URL: http://svn.apache.org/viewvc?rev=1916277&view=rev Log: Add CVE-2024-23672 and CVE-2024-24549 Modified: tomcat/site/trunk/docs/security-10.html tomcat/site/trunk/docs/security-11.html tomcat/site/trunk/docs/security-8.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-8.xml tomcat/site/trunk/xdocs/security-9.xml Modified: tomcat/site/trunk/docs/security-10.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-10.html?rev=1916277&r1=1916276&r2=1916277&view=diff == --- tomcat/site/trunk/docs/security-10.html (original) +++ tomcat/site/trunk/docs/security-10.html Wed Mar 13 15:41:32 2024 @@ -42,7 +42,38 @@ Table of Contents -Fixed 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 T omcat 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 +Fixed 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 Tomc at 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 + 2024-02-19 Fixed in Apache Tomcat 10.1.19 + +Important: Denial of Service + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-23672"; rel="nofollow">CVE-2024-23672 + +It was possible for a WebSocket client to keep a WebSocket connection + open leading to increased resource consumption. + +This was fixed with commit + https://github.com/apache/tomcat/commit/0052b374684b613b0c849899b325ebe334ac6501";>0052b374. + +This issue was identified by the Tomcat Security Team on 17 January 2024. + The issue was made public on 13 March 2024. + +Affects: 10.1.0-M1 to 10.1.18 + +Important: Denial of Service + http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-24549"; rel="nofollow">CVE-2024-24549 + +When processing an HTTP/2 request, if the request exceeded any of the + configured limits for headers, the associated HTTP/2 stream was not reset + until after all of the headers had been processed. + +This was fixed with commit + https://github.com/apache/tomcat/commit/d07c82194edb69d99b438828fe2cbfadbb207843";>d07c8219. + +This issue was reported to the Tomcat Security Team on 24 January 2024. The + issue was made public on 13 March 2024. + +Affects: 10.1.0-M1 to 10.1.18 + 2023-11-14 Fixed in Apache Tomcat 10.1.16 Important: Request smuggling Modified: tomcat/site/trunk/docs/security-11.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-11.html?rev=1916277&r1=1916276&r2=1916277&view=diff == --- tomcat/site/trunk/docs/security-11.html (original) +++ tomcat/site/trunk/docs/security-11.html Wed Mar 13 15:41:32 2024 @@ -36,7 +36,38 @@ Table of Contents -Fixed in Apache Tomcat 11.0.0-M12Fixed in Apache Tomcat 11.0.0-M11Fixed in Apache Tomcat 11.0.0-M6Fixed in Apache Tomcat 11.0.0-M5Fixed in Apache Tomcat 11.0.0-M3 +Fixed in Apache Tomcat 11.0.0-M17Fixed in Apache Tomcat 11.0.0-M12Fixed in Apache T
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
On 13/03/2024 14:38, Rémy Maucherat wrote: wrote: 1. A longer default nag-duration That's a good start. If it is meant to be enabled by default, I would like a value that is long enough so that it is almost certain there's an issue. 2 years ? Rémy 2. Add an explicit "disable" (e.g. -1) I was thinking yes to this and setting it to -1 by default. 3. Disable the feature by default 4. Remove this feature entirely The target for this was really 8.5 which will immediately go out-of-support once 8.5.100 is released. So really the default for 8.5.100 should be "nag immediately", but we can't expect that anybody really uses the out-of-the-box server.xml without any customizations, so specifically setting the duration to some small number of days in server.xml isn't going to have any effect. The more I think about this the more I wonder if some further tweaks are required. This check only runs at startup. There are some (very) long running Tomcat instances out there. Is on startup enough? Should this check be periodic? If yes, how periodic? Once a day? Probably whatever frequency we went for with the TLS reload warnings would be about right. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
n Wed, Mar 13, 2024 at 2:55 PM Christopher Schultz wrote: > > Rémy, > > On 3/12/24 12:05, Rémy Maucherat wrote: > > On Tue, Mar 12, 2024 at 3:02 PM Christopher Schultz > > wrote: > >> > >> Mark, > >> > >> On 3/12/24 05:00, Mark Thomas wrote: > >>> On 11/03/2024 21:38, schu...@apache.org wrote: > 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 > > commit 3ab883aa746a5c577efa39d9080858e53ca77da6 > Author: Christopher Schultz > AuthorDate: Mon Mar 11 17:38:01 2024 -0400 > > Add checking for the age of the Tomcat version running and warn > if it's getting old. > >>> > >>> How do I disable this check if I don't want to use it? I'd expect > >>> something like set it to "-1". > >> > >> I could add a special case for "disable" or you could set it to a very > >> high value. > >> > >> If your Tomcat installation is still running in 32768 days, you > >> certainly won't give a damn if it starts issuing warnings. > > > > I don't like this either. It might get me into real trouble with my > > downstream, actually. > > > > Unless there's a security issue, I think people don't really really > > have to upgrade working production systems that often. For example, > > between 9.0.62 and 9.0.71, no CVEs above low. And even if there was > > most often a user will not be affected. Upgrading costs testing and > > resources, so ... > > > > I'm not advocating that users should never upgrade, but building in a > > nag by default is not great. Esp 6 months. By the time things are > > upgraded they will start nagging again the next day pretty much. Then > > a warn log about security often cannot be simply ignored. > > Okay. Are you suggestion any of the following? > > 1. A longer default nag-duration That's a good start. If it is meant to be enabled by default, I would like a value that is long enough so that it is almost certain there's an issue. 2 years ? Rémy > 2. Add an explicit "disable" (e.g. -1) > > 3. Disable the feature by default > > 4. Remove this feature entirely > > The target for this was really 8.5 which will immediately go > out-of-support once 8.5.100 is released. So really the default for > 8.5.100 should be "nag immediately", but we can't expect that anybody > really uses the out-of-the-box server.xml without any customizations, so > specifically setting the duration to some small number of days in > server.xml isn't going to have any effect. > > That's why I made it "on by default". > > Another option would be: > > 5. Change the behavior between 8.5 and the other branches. 8.5 could > have this on-by-default while the others do not. We might make it a > policy to "change to on-by-default around EOL time" so that most people > will not change the configuration from the default, but then the default > changes for the final release(s) in a branch. > > In terms of "you only need to upgrade if there are CVEs"... that would > be a very difficult policy for us to manage, because any release we know > has any CVEs would be released before we knew it had them. Any new > release with fixes cannot announce to the old releases that they need to > be upgraded. > > My goal was to improve security for those who are unlikely to be paying > attention to announce@tomcat or using any of the publicly (and > non-publicly) available bug trackers and services to ensure they aren't > running vulnerable versions of Tomcat. > > We often release fixes without announcing them until long after the > fact, which means that any new release could conceivably be a "security > release". You (downstream) won't know until later whether or not you > should have upgraded. So the best advice is to upgrade as often as it is > convenient for you to do so. This is simply a reminder to do it. > > Since we have releases roughly every month, I figured that > every-6-months would be a good cadence. And it can always be configured > to shut up "forever" if necessary. > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
Rémy, On 3/12/24 12:05, Rémy Maucherat wrote: On Tue, Mar 12, 2024 at 3:02 PM Christopher Schultz wrote: Mark, On 3/12/24 05:00, Mark Thomas wrote: On 11/03/2024 21:38, schu...@apache.org wrote: 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 commit 3ab883aa746a5c577efa39d9080858e53ca77da6 Author: Christopher Schultz AuthorDate: Mon Mar 11 17:38:01 2024 -0400 Add checking for the age of the Tomcat version running and warn if it's getting old. How do I disable this check if I don't want to use it? I'd expect something like set it to "-1". I could add a special case for "disable" or you could set it to a very high value. If your Tomcat installation is still running in 32768 days, you certainly won't give a damn if it starts issuing warnings. I don't like this either. It might get me into real trouble with my downstream, actually. Unless there's a security issue, I think people don't really really have to upgrade working production systems that often. For example, between 9.0.62 and 9.0.71, no CVEs above low. And even if there was most often a user will not be affected. Upgrading costs testing and resources, so ... I'm not advocating that users should never upgrade, but building in a nag by default is not great. Esp 6 months. By the time things are upgraded they will start nagging again the next day pretty much. Then a warn log about security often cannot be simply ignored. Okay. Are you suggestion any of the following? 1. A longer default nag-duration 2. Add an explicit "disable" (e.g. -1) 3. Disable the feature by default 4. Remove this feature entirely The target for this was really 8.5 which will immediately go out-of-support once 8.5.100 is released. So really the default for 8.5.100 should be "nag immediately", but we can't expect that anybody really uses the out-of-the-box server.xml without any customizations, so specifically setting the duration to some small number of days in server.xml isn't going to have any effect. That's why I made it "on by default". Another option would be: 5. Change the behavior between 8.5 and the other branches. 8.5 could have this on-by-default while the others do not. We might make it a policy to "change to on-by-default around EOL time" so that most people will not change the configuration from the default, but then the default changes for the final release(s) in a branch. In terms of "you only need to upgrade if there are CVEs"... that would be a very difficult policy for us to manage, because any release we know has any CVEs would be released before we knew it had them. Any new release with fixes cannot announce to the old releases that they need to be upgraded. My goal was to improve security for those who are unlikely to be paying attention to announce@tomcat or using any of the publicly (and non-publicly) available bug trackers and services to ensure they aren't running vulnerable versions of Tomcat. We often release fixes without announcing them until long after the fact, which means that any new release could conceivably be a "security release". You (downstream) won't know until later whether or not you should have upgraded. So the best advice is to upgrade as often as it is convenient for you to do so. This is simply a reminder to do it. Since we have releases roughly every month, I figured that every-6-months would be a good cadence. And it can always be configured to shut up "forever" if necessary. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch 8.5.x updated: Correctly handle tag libraries packaged in JARs in a WAR deployment
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/8.5.x by this push:
new 0675222e36 Correctly handle tag libraries packaged in JARs in a WAR
deployment
0675222e36 is described below
commit 0675222e36129a1b49449add1e6418877affdce1
Author: Mark Thomas
AuthorDate: Wed Mar 13 11:18:27 2024 +
Correctly handle tag libraries packaged in JARs in a WAR deployment
This fixes a JSP TCK test. It is likely a long standing bug but wasn't
detected as, prior to Jakarta EE 11, the TCK provided web applications
were unpacked prior to test execution.
---
java/org/apache/jasper/compiler/TagLibraryInfoImpl.java | 8
res/checkstyle/org-import-control.xml | 1 +
webapps/docs/changelog.xml | 5 +
3 files changed, 14 insertions(+)
diff --git a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
index fbad12e42e..acf3ee07e4 100644
--- a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
+++ b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
@@ -45,6 +45,7 @@ import javax.servlet.jsp.tagext.ValidationMessage;
import org.apache.jasper.JasperException;
import org.apache.jasper.JspCompilationContext;
import org.apache.tomcat.Jar;
+import org.apache.tomcat.util.buf.UriUtil;
import org.apache.tomcat.util.descriptor.tld.TagFileXml;
import org.apache.tomcat.util.descriptor.tld.TagXml;
import org.apache.tomcat.util.descriptor.tld.TaglibXml;
@@ -268,6 +269,13 @@ class TagLibraryInfoImpl extends TagLibraryInfo implements
TagConstants {
URL url = null;
try {
url = ctxt.getResource(uri);
+/*
+ * When the TLD cache is built for a TLD contained within a JAR
within a WAR, the jar form of the URL is
+ * used for any nested JAR.
+ */
+if (url.getProtocol().equals("war") && uri.endsWith(".jar")) {
+url = UriUtil.warToJar(url);
+}
} catch (Exception ex) {
err.jspError("jsp.error.tld.unable_to_get_jar", uri,
ex.toString());
}
diff --git a/res/checkstyle/org-import-control.xml
b/res/checkstyle/org-import-control.xml
index 9b4b6d0677..637d753193 100644
--- a/res/checkstyle/org-import-control.xml
+++ b/res/checkstyle/org-import-control.xml
@@ -102,6 +102,7 @@
+
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 0737d6d24f..bf466d1113 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -167,6 +167,11 @@
IllegalStateException on code paths where there was a
subsequent attempt to obtain a Writer. (markt)
+
+Correctly handle the case where a tag library is packaged in a JAR file
+and the web application is deployed as a WAR file rather than an
+unpacked directory. (markt)
+
-
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: Correctly handle tag libraries packaged in JARs in a WAR deployment
This is an automated email from the ASF dual-hosted git repository.
markt 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 bf302b226b Correctly handle tag libraries packaged in JARs in a WAR
deployment
bf302b226b is described below
commit bf302b226b6e1387a7cf163dcaddfd86b818058e
Author: Mark Thomas
AuthorDate: Wed Mar 13 11:18:27 2024 +
Correctly handle tag libraries packaged in JARs in a WAR deployment
This fixes a JSP TCK test. It is likely a long standing bug but wasn't
detected as, prior to Jakarta EE 11, the TCK provided web applications
were unpacked prior to test execution.
---
java/org/apache/jasper/compiler/TagLibraryInfoImpl.java | 8
res/checkstyle/org-import-control.xml | 1 +
webapps/docs/changelog.xml | 5 +
3 files changed, 14 insertions(+)
diff --git a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
index a2138534f7..6fca6ee126 100644
--- a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
+++ b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
@@ -45,6 +45,7 @@ import javax.servlet.jsp.tagext.ValidationMessage;
import org.apache.jasper.JasperException;
import org.apache.jasper.JspCompilationContext;
import org.apache.tomcat.Jar;
+import org.apache.tomcat.util.buf.UriUtil;
import org.apache.tomcat.util.descriptor.tld.TagFileXml;
import org.apache.tomcat.util.descriptor.tld.TagXml;
import org.apache.tomcat.util.descriptor.tld.TaglibXml;
@@ -268,6 +269,13 @@ class TagLibraryInfoImpl extends TagLibraryInfo implements
TagConstants {
URL url = null;
try {
url = ctxt.getResource(uri);
+/*
+ * When the TLD cache is built for a TLD contained within a JAR
within a WAR, the jar form of the URL is
+ * used for any nested JAR.
+ */
+if (url.getProtocol().equals("war") && uri.endsWith(".jar")) {
+url = UriUtil.warToJar(url);
+}
} catch (Exception ex) {
err.jspError("jsp.error.tld.unable_to_get_jar", uri,
ex.toString());
}
diff --git a/res/checkstyle/org-import-control.xml
b/res/checkstyle/org-import-control.xml
index 1ab2d1251d..e96b2d346a 100644
--- a/res/checkstyle/org-import-control.xml
+++ b/res/checkstyle/org-import-control.xml
@@ -109,6 +109,7 @@
+
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index b49bdc64fe..9d9709c21e 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -139,6 +139,11 @@
IllegalStateException on code paths where there was a
subsequent attempt to obtain a Writer. (markt)
+
+Correctly handle the case where a tag library is packaged in a JAR file
+and the web application is deployed as a WAR file rather than an
+unpacked directory. (markt)
+
-
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: Correctly handle tag libraries packaged in JARs in a WAR deployment
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 f159cd54c1 Correctly handle tag libraries packaged in JARs in a WAR
deployment
f159cd54c1 is described below
commit f159cd54c1bfc198797eccbac5fb2d5e40811139
Author: Mark Thomas
AuthorDate: Wed Mar 13 11:18:27 2024 +
Correctly handle tag libraries packaged in JARs in a WAR deployment
This fixes a JSP TCK test. It is likely a long standing bug but wasn't
detected as, prior to Jakarta EE 11, the TCK provided web applications
were unpacked prior to test execution.
---
java/org/apache/jasper/compiler/TagLibraryInfoImpl.java | 8
res/checkstyle/org-import-control.xml | 1 +
webapps/docs/changelog.xml | 5 +
3 files changed, 14 insertions(+)
diff --git a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
index d7f1ab4847..fa247aaade 100644
--- a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
+++ b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
@@ -45,6 +45,7 @@ import jakarta.servlet.jsp.tagext.ValidationMessage;
import org.apache.jasper.JasperException;
import org.apache.jasper.JspCompilationContext;
import org.apache.tomcat.Jar;
+import org.apache.tomcat.util.buf.UriUtil;
import org.apache.tomcat.util.descriptor.tld.TagFileXml;
import org.apache.tomcat.util.descriptor.tld.TagXml;
import org.apache.tomcat.util.descriptor.tld.TaglibXml;
@@ -268,6 +269,13 @@ class TagLibraryInfoImpl extends TagLibraryInfo implements
TagConstants {
URL url = null;
try {
url = ctxt.getResource(uri);
+/*
+ * When the TLD cache is built for a TLD contained within a JAR
within a WAR, the jar form of the URL is
+ * used for any nested JAR.
+ */
+if (url.getProtocol().equals("war") && uri.endsWith(".jar")) {
+url = UriUtil.warToJar(url);
+}
} catch (Exception ex) {
err.jspError("jsp.error.tld.unable_to_get_jar", uri,
ex.toString());
}
diff --git a/res/checkstyle/org-import-control.xml
b/res/checkstyle/org-import-control.xml
index 29ea88f313..b6d877321d 100644
--- a/res/checkstyle/org-import-control.xml
+++ b/res/checkstyle/org-import-control.xml
@@ -112,6 +112,7 @@
+
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index a5290dd74c..d26fdd6813 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -195,6 +195,11 @@
IllegalStateException on code paths where there was a
subsequent attempt to obtain a Writer. (markt)
+
+Correctly handle the case where a tag library is packaged in a JAR file
+and the web application is deployed as a WAR file rather than an
+unpacked directory. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) branch main updated: Correctly handle tag libraries packaged in JARs in a WAR deployment
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 459c12275f Correctly handle tag libraries packaged in JARs in a WAR
deployment
459c12275f is described below
commit 459c12275f40f999a106a7c5d2ff9ce22e0e9d96
Author: Mark Thomas
AuthorDate: Wed Mar 13 11:18:27 2024 +
Correctly handle tag libraries packaged in JARs in a WAR deployment
This fixes a JSP TCK test. It is likely a long standing bug but wasn't
detected as, prior to Jakarta EE 11, the TCK provided web applications
were unpacked prior to test execution.
---
java/org/apache/jasper/compiler/TagLibraryInfoImpl.java | 8
res/checkstyle/org-import-control.xml | 1 +
webapps/docs/changelog.xml | 5 +
3 files changed, 14 insertions(+)
diff --git a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
index d7f1ab4847..fa247aaade 100644
--- a/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
+++ b/java/org/apache/jasper/compiler/TagLibraryInfoImpl.java
@@ -45,6 +45,7 @@ import jakarta.servlet.jsp.tagext.ValidationMessage;
import org.apache.jasper.JasperException;
import org.apache.jasper.JspCompilationContext;
import org.apache.tomcat.Jar;
+import org.apache.tomcat.util.buf.UriUtil;
import org.apache.tomcat.util.descriptor.tld.TagFileXml;
import org.apache.tomcat.util.descriptor.tld.TagXml;
import org.apache.tomcat.util.descriptor.tld.TaglibXml;
@@ -268,6 +269,13 @@ class TagLibraryInfoImpl extends TagLibraryInfo implements
TagConstants {
URL url = null;
try {
url = ctxt.getResource(uri);
+/*
+ * When the TLD cache is built for a TLD contained within a JAR
within a WAR, the jar form of the URL is
+ * used for any nested JAR.
+ */
+if (url.getProtocol().equals("war") && uri.endsWith(".jar")) {
+url = UriUtil.warToJar(url);
+}
} catch (Exception ex) {
err.jspError("jsp.error.tld.unable_to_get_jar", uri,
ex.toString());
}
diff --git a/res/checkstyle/org-import-control.xml
b/res/checkstyle/org-import-control.xml
index 2023550efc..170305cf0d 100644
--- a/res/checkstyle/org-import-control.xml
+++ b/res/checkstyle/org-import-control.xml
@@ -112,6 +112,7 @@
+
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 4f3e7a605d..c77301a8fa 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -139,6 +139,11 @@
IllegalStateException on code paths where there was a
subsequent attempt to obtain a Writer. (markt)
+
+Correctly handle the case where a tag library is packaged in a JAR file
+and the web application is deployed as a WAR file rather than an
+unpacked directory. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 9.0.87
On 11/03/2024 11:09, Rémy Maucherat wrote: The proposed 9.0.87 release is: [ ] -1, Broken - do not release [X] +1, Stable - go ahead and release as 9.0.87 Tests pass on Linux, Windows and MacOS (M1). I'm currently unable to test on Intel MacOS due to security software recently installed by $dayjob. The build is repeatable. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
