Buildbot failure in on tomcat-8.5.x
Build status: BUILD FAILED: failed compile (failure) Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/36/builds/743 Blamelist: Mark Thomas Build Text: failed compile (failure) Status Detected: new failure Build Source Stamp: [branch 8.5.x] b0df9819c8d130adab0490b89dce1ab4ca6a3448 Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 compile: 1 shell_6: 0 shell_7: 0 shell_8: 0 shell_9: 0 Rsync docs to nightlies.apache.org: 0 shell_10: 0 Rsync RAT to nightlies.apache.org: 0 compile_1: 2 shell_11: 0 Rsync Logs to nightlies.apache.org: 0 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
Woellchen commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932961663 Alright, I guess I got this wrong then, thanks for your detailed explanations. In case others are wondering about the same issue I found two bugs for reference on prominent software projects that apparently implemented it wrong then: - https://github.com/golang/go/issues/3659 - https://trac.nginx.org/nginx/ticket/727 -- 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] Decode and normalize URIs before processing them [tomcat]
markt-asf commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932891346 Nope, `%2F` is NOT equivalent to `/` in a URI as explained in section 2.2 of RFC 3986. -- 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] Decode and normalize URIs before processing them [tomcat]
Woellchen commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932841669 Thanks for checking back! The section you are referring to does not really negate my statement however. If I get you right you are talking about this specific thing? > These URIs should be normalized by decoding any percent-encoded octet **that corresponds to an unreserved character** This does not mean that reserved characters can't be decoded or? Maybe we can debate this together to clear my confusion. Let me point out to you the relevant parts of the RFC that I am talking about: **2.4. When to Encode or Decode** > Once produced, a URI is always in its percent-encoded form. That means, a URI should be decoded to properly process it right? > When a URI is dereferenced, the components and subcomponents [...] must be parsed and separated before the percent-encoded octets within those components can be safely decoded, as otherwise the data may be mistaken for component delimiters. This has been done, my change only affects the path component of the whole scheme. That means the components were already separated and decoding can take place, also for delimiters. Note that decoding unreserved characters can optionally happen anytime earlier: > [...] percent-encoded octets corresponding to characters in the unreserved set, which **can be decoded at any time**. Also check the example from **5.4. Reference Resolution Examples**: A base URI of `http://a/b/c/d;p?q` and a relative path of `g;x=1/../y` should resolve to `http://a/b/c/y`. One more note to parent directories, as they are totally valid and should be normalized as well. Just to clear this up, taken from **3.3. Path**: > The path segments "." and "..", also known as dot-segments, are defined for relative reference within the path name hierarchy [...] to indicate relative position within the hierarchical tree of names. This is similar to their role within some operating systems' file directory structures to indicate the current directory and **parent directory**, respectively. -- 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
Buildbot failure in on tomcat-9.0.x
Build status: BUILD FAILED: failed compile (failure) Worker used: bb_worker2_ubuntu URL: https://ci2.apache.org/#builders/37/builds/845 Blamelist: Mark Thomas Build Text: failed compile (failure) Status Detected: new failure Build Source Stamp: [branch 9.0.x] 6ce18dc93a054949e529952e809b159040b1d158 Steps: worker_preparation: 0 git: 0 shell: 0 shell_1: 0 shell_2: 0 shell_3: 0 shell_4: 0 shell_5: 0 compile: 1 shell_6: 0 shell_7: 0 shell_8: 0 shell_9: 0 Rsync docs to nightlies.apache.org: 0 shell_10: 0 Rsync RAT to nightlies.apache.org: 0 compile_1: 2 shell_11: 0 Rsync Logs to nightlies.apache.org: 0 -- ASF Buildbot - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68596] Remaining overhead in javax.el.CompositeELResolver.convertToType
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596 --- Comment #3 from John Engebretson --- > This needs some more thought... Thanks, I'll keep chewing on it too. > Note: This may get moved to an enhancement if there isn't an obvious way to > improve this) Makes sense, 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
[Bug 68596] Remaining overhead in javax.el.CompositeELResolver.convertToType
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596 --- Comment #2 from Mark Thomas --- #1 isn't an option unfortunately. With more complex EL expressions ELContext.isPropertyResolved() will return true at the start of the call to convertToType(). At least one test fails if this code is removed. I don't see how we can do #2 without, effectively, making the existing setPropertyResolved() methods final which undermines the point of them being non-final in the first place. Our options here are further limited by ELContext being a specification class which means we can't change the public API. This needs some more thought... Note: This may get moved to an enhancement if there isn't an obvious way to improve this) -- 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 8.5.x updated: Allow user provided SSLContext instances on SSLHostConfigCertificate
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 b0df9819c8 Allow user provided SSLContext instances on
SSLHostConfigCertificate
b0df9819c8 is described below
commit b0df9819c8d130adab0490b89dce1ab4ca6a3448
Author: Mark Thomas
AuthorDate: Wed Feb 7 13:47:32 2024 +
Allow user provided SSLContext instances on SSLHostConfigCertificate
Based on pull request #673 provided by Hakan Altındağ
https://github.com/apache/tomcat/pull/673
---
.../apache/tomcat/util/net/AbstractEndpoint.java | 4 ++-
.../tomcat/util/net/AbstractJsseEndpoint.java | 22 ++--
.../tomcat/util/net/SSLHostConfigCertificate.java | 29 +-
webapps/docs/changelog.xml | 5
4 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index e6d170c260..a23f409bcc 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -472,7 +472,8 @@ public abstract class AbstractEndpoint {
protected void releaseSSLContext(SSLHostConfig sslHostConfig) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates(true)) {
if (certificate.getSslContext() != null) {
-SSLContext sslContext = certificate.getSslContext();
+// Only release the SSLContext if we generated it.
+SSLContext sslContext = certificate.getSslContextGenerated();
if (sslContext != null) {
sslContext.destroy();
}
@@ -1317,6 +1318,7 @@ public abstract class AbstractEndpoint {
public abstract void bind() throws Exception;
public abstract void unbind() throws Exception;
+
public abstract void startInternal() throws Exception;
public abstract void stopInternal() throws Exception;
diff --git a/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
index 32c8c40ac5..39179814d6 100644
--- a/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
@@ -101,14 +101,18 @@ public abstract class AbstractJsseEndpoint extends
AbstractEndpoint {
sslHostConfig.setEnabledCiphers(sslUtil.getEnabledCiphers());
}
-SSLContext sslContext;
-try {
-sslContext = sslUtil.createSSLContext(negotiableProtocols);
-} catch (Exception e) {
-throw new IllegalArgumentException(e.getMessage(), e);
+SSLContext sslContext = certificate.getSslContext();
+// Generate the SSLContext from configuration unless (e.g.
embedded) an SSLContext has been provided.
+if (sslContext == null) {
+try {
+sslContext = sslUtil.createSSLContext(negotiableProtocols);
+} catch (Exception e) {
+throw new IllegalArgumentException(e.getMessage(), e);
+}
+
+certificate.setSslContextGenerated(sslContext);
}
-certificate.setSslContext(sslContext);
logCertificate(certificate);
}
}
@@ -251,7 +255,11 @@ public abstract class AbstractJsseEndpoint extends
AbstractEndpoint {
public void unbind() throws Exception {
for (SSLHostConfig sslHostConfig : sslHostConfigs.values()) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates(true)) {
-certificate.setSslContext(null);
+/*
+ * Only remove any generated SSLContext. If the SSLContext was
provided it is left in place in case the
+ * endpoint is re-started.
+ */
+certificate.setSslContextGenerated(null);
}
}
}
diff --git a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
index 4b7b2a4c70..e50b4b0c5d 100644
--- a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
+++ b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
@@ -50,10 +50,14 @@ public class SSLHostConfigCertificate implements
Serializable {
// Internal
private ObjectName oname;
-// OpenSSL can handle multiple certs in a single config so the reference to
-// the context is at the virtual host level. JSSE can't so the reference is
-// held here on the certificate.
-private transient volatile SSLContext sslContext;
+/*
+ * OpenSSL can handle multiple certs in a single config so the reference
to the
(tomcat) branch 10.1.x updated: Align with 11.0.x
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 95ca454cc2 Align with 11.0.x
95ca454cc2 is described below
commit 95ca454cc2c1757c3a40d191b19ad029d6e70cff
Author: Mark Thomas
AuthorDate: Wed Feb 7 19:45:25 2024 +
Align with 11.0.x
---
java/org/apache/tomcat/jni/SSL.java | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/java/org/apache/tomcat/jni/SSL.java
b/java/org/apache/tomcat/jni/SSL.java
index 974e998c7d..4fff8081b9 100644
--- a/java/org/apache/tomcat/jni/SSL.java
+++ b/java/org/apache/tomcat/jni/SSL.java
@@ -241,7 +241,7 @@ public final class SSL {
public static final int SSL_SELECTOR_FAILURE_NO_ADVERTISE = 0;
public static final int SSL_SELECTOR_FAILURE_CHOOSE_MY_LAST_PROTOCOL = 1;
-/* Return OpenSSL version number (compile time version, if version <
1.1.0) */
+/* Return OpenSSL version number (run time version) */
public static native int version();
/* Return OpenSSL version string (run time version) */
-
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: Allow user provided SSLContext instances on SSLHostConfigCertificate
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 6ce18dc93a Allow user provided SSLContext instances on
SSLHostConfigCertificate
6ce18dc93a is described below
commit 6ce18dc93a054949e529952e809b159040b1d158
Author: Mark Thomas
AuthorDate: Wed Feb 7 13:47:32 2024 +
Allow user provided SSLContext instances on SSLHostConfigCertificate
Based on pull request #673 provided by Hakan Altındağ
https://github.com/apache/tomcat/pull/673
---
.../apache/tomcat/util/net/AbstractEndpoint.java | 4 ++-
.../tomcat/util/net/AbstractJsseEndpoint.java | 22 ++--
.../tomcat/util/net/SSLHostConfigCertificate.java | 29 +-
webapps/docs/changelog.xml | 5
4 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index 53fcea14b7..05a1ede2ec 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -474,7 +474,8 @@ public abstract class AbstractEndpoint {
protected void releaseSSLContext(SSLHostConfig sslHostConfig) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates(true)) {
if (certificate.getSslContext() != null) {
-SSLContext sslContext = certificate.getSslContext();
+// Only release the SSLContext if we generated it.
+SSLContext sslContext = certificate.getSslContextGenerated();
if (sslContext != null) {
sslContext.destroy();
}
@@ -1323,6 +1324,7 @@ public abstract class AbstractEndpoint {
public abstract void bind() throws Exception;
public abstract void unbind() throws Exception;
+
public abstract void startInternal() throws Exception;
public abstract void stopInternal() throws Exception;
diff --git a/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
index 7db261d825..b2a3390c6a 100644
--- a/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
@@ -100,14 +100,18 @@ public abstract class AbstractJsseEndpoint extends
AbstractEndpoint {
sslHostConfig.setEnabledCiphers(sslUtil.getEnabledCiphers());
}
-SSLContext sslContext;
-try {
-sslContext = sslUtil.createSSLContext(negotiableProtocols);
-} catch (Exception e) {
-throw new IllegalArgumentException(e.getMessage(), e);
+SSLContext sslContext = certificate.getSslContext();
+// Generate the SSLContext from configuration unless (e.g.
embedded) an SSLContext has been provided.
+if (sslContext == null) {
+try {
+sslContext = sslUtil.createSSLContext(negotiableProtocols);
+} catch (Exception e) {
+throw new IllegalArgumentException(e.getMessage(), e);
+}
+
+certificate.setSslContextGenerated(sslContext);
}
-certificate.setSslContext(sslContext);
logCertificate(certificate);
}
}
@@ -223,7 +227,11 @@ public abstract class AbstractJsseEndpoint extends
AbstractEndpoint {
public void unbind() throws Exception {
for (SSLHostConfig sslHostConfig : sslHostConfigs.values()) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates(true)) {
-certificate.setSslContext(null);
+/*
+ * Only remove any generated SSLContext. If the SSLContext was
provided it is left in place in case the
+ * endpoint is re-started.
+ */
+certificate.setSslContextGenerated(null);
}
}
}
diff --git a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
index 4b7b2a4c70..e50b4b0c5d 100644
--- a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
+++ b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
@@ -50,10 +50,14 @@ public class SSLHostConfigCertificate implements
Serializable {
// Internal
private ObjectName oname;
-// OpenSSL can handle multiple certs in a single config so the reference to
-// the context is at the virtual host level. JSSE can't so the reference is
-// held here on the certificate.
-private transient volatile SSLContext sslContext;
+/*
+ * OpenSSL can handle multiple certs in a single config so the reference
to the
[Bug 68089] ApplicationHttpRequest.getSpecial() and removeSpecial() use linear scans
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089 --- Comment #8 from John Engebretson --- Created attachment 39575 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39575=edit Support class for the speed 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 68089] ApplicationHttpRequest.getSpecial() and removeSpecial() use linear scans
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089 --- Comment #7 from John Engebretson --- Created attachment 39574 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39574=edit Speed 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
Re: Moving to Tomcat Native 1.3.x
On 2024/02/07 16:05:17 Michael Osipov wrote: > On 2024/02/04 19:54:25 Mark Thomas wrote: > > Hi all, > > > > AS you have probably noticed I am working on another round of Tomcat > > Native releases. > > > > We are overdue on switching to 1.3.x so I would like to propose the > > following with this release round: > > > > - create a new 1.3.x branch from the current 1.2.x HEAD > > - update minimum OpenSSL to 1.1.1 > > - update minimum APR to 1.6.3 > > - remove code supporting OpenSSL < 1.1.1 > > > > The next 8.5.x and 9.0.x releases would then ship with Tomcat Native > > 1.3.0 but minimum required/recommended Tomcat Native versions would not > > change. > > I have just tested Tomcat 9.0.x from Git repo against: > FreeBSD 13-STABLE: > OpenSSL 1.1.1w-freebsd 11 Sep 2023 > Tomcat Native library [1.3.1-dev] using APR version [1.7.3] > > > HP-UX 11.31: > OpenSSL 1.1.1w 11 Sep 2023 > Tomcat Native library [1.3.1-dev] using APR version [1.7.4] > > I will try with OpenSSL 3.0.x soon. It is very unfortunate that 9.0.x > requires Java 17 to build, it is not available on HP-UX and will never be by > HPE. I had to downgrade BND to 6.4.0 to make it run. I still consider this a > wrong move for at least Tomcat 9.0.x, Java 11 should have stayed the minimum. Both setups do also work with OpenSSL 3.0.13 30 Jan 2024 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68089] ApplicationHttpRequest.getSpecial() and removeSpecial() use linear scans
https://bz.apache.org/bugzilla/show_bug.cgi?id=68089 John Engebretson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from John Engebretson --- Production data confirms the behavior change but shows minimal actual performance improvement - it appears the extra work of hashing the string and doing the HashMap lookup is comparable to the wasted effort of 12 string comparisons. I refined the approach by checking whether the attribute name was shorter than the shortest special (length 30) and that eliminates the search cost for the vast majority of calls. The attached speed test compares the cost of searching for attributes with long vs. short names, and the current implementation of getAttribute() is indeed slightly faster for short names (520ms vs. 540ms on my PC). With the length check, the short names are orders of magnitudes faster. Presumably the JIT optimized it close to a no-op. Checking for length 30 is an easy modification, but not the most maintainable. Perhaps modify the static initializer to calculate the length of the shortest special? -- 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: Moving to Tomcat Native 1.3.x
On 2024/02/07 18:19:24 Christopher Schultz wrote:
> Michael,
>
> On 2/7/24 11:05, Michael Osipov wrote:
> > On 2024/02/04 19:54:25 Mark Thomas wrote:
> >> Hi all,
> >>
> >> AS you have probably noticed I am working on another round of Tomcat
> >> Native releases.
> >>
> >> We are overdue on switching to 1.3.x so I would like to propose the
> >> following with this release round:
> >>
> >> - create a new 1.3.x branch from the current 1.2.x HEAD
> >> - update minimum OpenSSL to 1.1.1
> >> - update minimum APR to 1.6.3
> >> - remove code supporting OpenSSL < 1.1.1
> >>
> >> The next 8.5.x and 9.0.x releases would then ship with Tomcat Native
> >> 1.3.0 but minimum required/recommended Tomcat Native versions would not
> >> change.
> >
> > I have just tested Tomcat 9.0.x from Git repo against:
> > FreeBSD 13-STABLE:
> > OpenSSL 1.1.1w-freebsd 11 Sep 2023
> > Tomcat Native library [1.3.1-dev] using APR version [1.7.3]
> >
> >
> > HP-UX 11.31:
> > OpenSSL 1.1.1w 11 Sep 2023
> > Tomcat Native library [1.3.1-dev] using APR version [1.7.4]
> >
> > I will try with OpenSSL 3.0.x soon. It is very unfortunate that 9.0.x
> > requires Java 17 to build, it is not available on HP-UX and will never be
> > by HPE. I had to downgrade BND to 6.4.0 to make it run. I still consider
> > this a wrong move for at least Tomcat 9.0.x, Java 11 should have stayed the
> > minimum.
>
> I think it's actually possible to build with Java 11, but the release
> builds require Java 17 for #reasons.
>
> Try just hacking the build files to allow Java 11 and see if you can build.
It does work:
diff --git a/build.properties.default b/build.properties.default
index 2ec1dbfb16..82aec7debb 100644
--- a/build.properties.default
+++ b/build.properties.default
@@ -307 +307 @@
spotbugs.loc=${base-maven.loc}/com/github/spotbugs/spotbugs/${spotbugs.version}/
-bnd.version=7.0.0
+bnd.version=6.4.0
diff --git a/build.xml b/build.xml
index 94e80620e2..83852a889f 100644
--- a/build.xml
+++ b/build.xml
@@ -110 +110 @@
-
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Decode and normalize URIs before processing them [tomcat]
markt-asf commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932635647 Nope. Read the RFC again. Specifically 6.2.2.2. -- 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: Moving to Tomcat Native 1.3.x
Michael, On 2/7/24 11:05, Michael Osipov wrote: On 2024/02/04 19:54:25 Mark Thomas wrote: Hi all, AS you have probably noticed I am working on another round of Tomcat Native releases. We are overdue on switching to 1.3.x so I would like to propose the following with this release round: - create a new 1.3.x branch from the current 1.2.x HEAD - update minimum OpenSSL to 1.1.1 - update minimum APR to 1.6.3 - remove code supporting OpenSSL < 1.1.1 The next 8.5.x and 9.0.x releases would then ship with Tomcat Native 1.3.0 but minimum required/recommended Tomcat Native versions would not change. I have just tested Tomcat 9.0.x from Git repo against: FreeBSD 13-STABLE: OpenSSL 1.1.1w-freebsd 11 Sep 2023 Tomcat Native library [1.3.1-dev] using APR version [1.7.3] HP-UX 11.31: OpenSSL 1.1.1w 11 Sep 2023 Tomcat Native library [1.3.1-dev] using APR version [1.7.4] I will try with OpenSSL 3.0.x soon. It is very unfortunate that 9.0.x requires Java 17 to build, it is not available on HP-UX and will never be by HPE. I had to downgrade BND to 6.4.0 to make it run. I still consider this a wrong move for at least Tomcat 9.0.x, Java 11 should have stayed the minimum. I think it's actually possible to build with Java 11, but the release builds require Java 17 for #reasons. Try just hacking the build files to allow Java 11 and see if you can build. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 68119] Significant overhead in javax.el.CompositeELResolver.convertToType
https://bz.apache.org/bugzilla/show_bug.cgi?id=68119 --- Comment #3 from John Engebretson --- This optimization was effective in production and reduced the method cost by approximately 2/3rds, saving more than 0.5% of cpu. The remaining time comes from another invokevirtual in the method which I overlooked. I've opened a separate issue to address that. https://bz.apache.org/bugzilla/show_bug.cgi?id=68596 -- 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 68596] Remaining overhead in javax.el.CompositeELResolver.convertToType
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596 --- Comment #1 from John Engebretson --- Created attachment 39573 --> https://bz.apache.org/bugzilla/attachment.cgi?id=39573=edit Support class for the speed 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 68596] New: Remaining overhead in javax.el.CompositeELResolver.convertToType
https://bz.apache.org/bugzilla/show_bug.cgi?id=68596
Bug ID: 68596
Summary: Remaining overhead in
javax.el.CompositeELResolver.convertToType
Product: Tomcat 9
Version: 9.0.85
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Jasper
Assignee: dev@tomcat.apache.org
Reporter: jeng...@amazon.com
Target Milestone: -
Created attachment 39572
--> https://bz.apache.org/bugzilla/attachment.cgi?id=39572=edit
Speed test
This issue was identified in production after deploying the fix for
https://bz.apache.org/bugzilla/show_bug.cgi?id=68119 and is an opportunity to
further improve the original hotspot.
Production data showed the other issue generated approximately a 2/3rds
reduction in the cost of javax.el.CompositeELResolver.convertToType; this is
less than predicted because of an overlooked virtual call:
public Object convertToType(ELContext context, Object obj, Class type) {
context.setPropertyResolved(false);
...
}
context can be of type ELContextImpl, ELContextWrapper, EvaluationContext, or
StandardELContext so this method triggers an invokevirtual.
My tests associated with the previous issue only included one type of ELContext
and the method was effectively final, allowing the JIT to eliminate the lookup.
The fresh test attached to this ticket demonstrates the performance difference
when one ELContext subclass is used versus three, where each subclass' code is
identical. On my PC the old-style test (one subclass) finished in
approximately 80ms but the new one (three subclasses) finishes in about 175ms.
The test also shows something else: commenting out
"context.setPropertyResolved(false);" in
RevisedCompositeELResolver.convertToType() causes the test to finish several
orders of magnitude faster. I assume the JIT converts the method to a no-op.
The potential solutions I see are:
1. Eliminate the seemingly-unnecessary call to setPropertyResolved(false). As
far as I can tell, the field is already false when convertToType() is called,
so this is a safe removal.
2. Create a final method on ELContext that somehow does the same work. I
implemented a final method on ELContext that returned a boolean
"needsToSetPropertyResolved", which was set by the constructor. This matched
the near-zero performance, however it required changes to each subclass, and
looks pretty hacky.
I'm hoping #1 is a good option. :)
--
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: [PR] Decode and normalize URIs before processing them [tomcat]
Woellchen commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932522774 Could you please elaborate how a URI is not user input and how it can be prevented that a user calls a URI on a web application? I can't follow you. Relative paths are explicitly allowed in URIs, and that includes parent directories as well, see the mentioned RFC that defines URIs and how to handle them. This PR was meant to fix a bug in the path processing of Tomcat because it does not decode slashes in paths and that leads to the stripping of the remainder of the URI after the `;` character. I have also added test cases for this issue. -- 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] Decode and normalize URIs before processing them [tomcat]
rmaucher commented on PR #687: URL: https://github.com/apache/tomcat/pull/687#issuecomment-1932491567 URL processing and mapping has to follow a lot of rules from specifications to avoid inconsistencies which would be security issues. So this is one of them. Indeed creative encoding can cause path traversals on the backends. To be honest, a good security practice is to not use user input as paths in your app, rather use some other kind of mapping. So no traversal then. -- 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] Decode and normalize URIs before processing them [tomcat]
rmaucher closed pull request #687: Decode and normalize URIs before processing them URL: https://github.com/apache/tomcat/pull/687 -- 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 68068] Hotspot in Ast*Nodes: itable method calls
https://bz.apache.org/bugzilla/show_bug.cgi?id=68068 --- Comment #5 from John Engebretson --- Production results confirm a small improvement - greater than zero but not enormous. Sorry, I'm not able to provide hard numbers because of the huge number of distinct code paths. -- 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: Moving to Tomcat Native 1.3.x
On 2024/02/04 19:54:25 Mark Thomas wrote: > Hi all, > > AS you have probably noticed I am working on another round of Tomcat > Native releases. > > We are overdue on switching to 1.3.x so I would like to propose the > following with this release round: > > - create a new 1.3.x branch from the current 1.2.x HEAD > - update minimum OpenSSL to 1.1.1 > - update minimum APR to 1.6.3 > - remove code supporting OpenSSL < 1.1.1 > > The next 8.5.x and 9.0.x releases would then ship with Tomcat Native > 1.3.0 but minimum required/recommended Tomcat Native versions would not > change. I have just tested Tomcat 9.0.x from Git repo against: FreeBSD 13-STABLE: OpenSSL 1.1.1w-freebsd 11 Sep 2023 Tomcat Native library [1.3.1-dev] using APR version [1.7.3] HP-UX 11.31: OpenSSL 1.1.1w 11 Sep 2023 Tomcat Native library [1.3.1-dev] using APR version [1.7.4] I will try with OpenSSL 3.0.x soon. It is very unfortunate that 9.0.x requires Java 17 to build, it is not available on HP-UX and will never be by HPE. I had to downgrade BND to 6.4.0 to make it run. I still consider this a wrong move for at least Tomcat 9.0.x, Java 11 should have stayed the minimum. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[PR] Decode and normalize URIs before processing them [tomcat]
Woellchen opened a new pull request, #687: URL: https://github.com/apache/tomcat/pull/687 URIs must be at least decoded in order to process sub-delims as defined in RFC 3986, because slashes and their encoded counterparts are equivalent when processing paths. Normalization before the processing also makes sense to avoid unnecessary stripping of path parameters in case of path traversal. This fixes a bug where URIs like "/test;%2F.." would not properly resolve to "/", but to "/test". -- 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] Added option to use custom SSLContext [tomcat]
Hakky54 commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-1932206483 Thank you mate, I really appreciate this! Big kudos! 拾 I am looking forward to the new release! -- 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 10.1.x updated: Allow user provided SSLContext instances on SSLHostConfigCertificate
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 85bff6d424 Allow user provided SSLContext instances on
SSLHostConfigCertificate
85bff6d424 is described below
commit 85bff6d42404fec548556354f4ac592fd1523a5f
Author: Mark Thomas
AuthorDate: Wed Feb 7 13:47:32 2024 +
Allow user provided SSLContext instances on SSLHostConfigCertificate
Based on pull request #673 provided by Hakan Altındağ
https://github.com/apache/tomcat/pull/673
---
.../apache/tomcat/util/net/AbstractEndpoint.java | 4 ++-
.../tomcat/util/net/AbstractJsseEndpoint.java | 22 ++--
.../tomcat/util/net/SSLHostConfigCertificate.java | 29 +-
webapps/docs/changelog.xml | 5
4 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index 8602b8ae7f..bcc2b9ecb9 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -458,7 +458,8 @@ public abstract class AbstractEndpoint {
protected void releaseSSLContext(SSLHostConfig sslHostConfig) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates()) {
if (certificate.getSslContext() != null) {
-SSLContext sslContext = certificate.getSslContext();
+// Only release the SSLContext if we generated it.
+SSLContext sslContext = certificate.getSslContextGenerated();
if (sslContext != null) {
sslContext.destroy();
}
@@ -1271,6 +1272,7 @@ public abstract class AbstractEndpoint {
public abstract void bind() throws Exception;
public abstract void unbind() throws Exception;
+
public abstract void startInternal() throws Exception;
public abstract void stopInternal() throws Exception;
diff --git a/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
index 0aabf8403a..b75002de38 100644
--- a/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
@@ -99,14 +99,18 @@ public abstract class AbstractJsseEndpoint extends
AbstractEndpoint {
sslHostConfig.setEnabledCiphers(sslUtil.getEnabledCiphers());
}
-SSLContext sslContext;
-try {
-sslContext = sslUtil.createSSLContext(negotiableProtocols);
-} catch (Exception e) {
-throw new IllegalArgumentException(e.getMessage(), e);
+SSLContext sslContext = certificate.getSslContext();
+// Generate the SSLContext from configuration unless (e.g.
embedded) an SSLContext has been provided.
+if (sslContext == null) {
+try {
+sslContext = sslUtil.createSSLContext(negotiableProtocols);
+} catch (Exception e) {
+throw new IllegalArgumentException(e.getMessage(), e);
+}
+
+certificate.setSslContextGenerated(sslContext);
}
-certificate.setSslContext(sslContext);
logCertificate(certificate);
}
}
@@ -202,7 +206,11 @@ public abstract class AbstractJsseEndpoint extends
AbstractEndpoint {
public void unbind() throws Exception {
for (SSLHostConfig sslHostConfig : sslHostConfigs.values()) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates()) {
-certificate.setSslContext(null);
+/*
+ * Only remove any generated SSLContext. If the SSLContext was
provided it is left in place in case the
+ * endpoint is re-started.
+ */
+certificate.setSslContextGenerated(null);
}
}
}
diff --git a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
index 4b7b2a4c70..e50b4b0c5d 100644
--- a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
+++ b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
@@ -50,10 +50,14 @@ public class SSLHostConfigCertificate implements
Serializable {
// Internal
private ObjectName oname;
-// OpenSSL can handle multiple certs in a single config so the reference to
-// the context is at the virtual host level. JSSE can't so the reference is
-// held here on the certificate.
-private transient volatile SSLContext sslContext;
+/*
+ * OpenSSL can handle multiple certs in a single config so the reference
to the context is
Re: [PR] Added option to use custom SSLContext [tomcat]
markt-asf commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-1932089608 OK, it is in main. I'll back-port as well. -- 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 main updated: Allow user provided SSLContext instances on SSLHostConfigCertificate
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 e6da237431 Allow user provided SSLContext instances on
SSLHostConfigCertificate
e6da237431 is described below
commit e6da2374315f322a7abf24d4a3faddfea7a3f7f0
Author: Mark Thomas
AuthorDate: Wed Feb 7 13:47:32 2024 +
Allow user provided SSLContext instances on SSLHostConfigCertificate
Based on pull request #673 provided by Hakan Altındağ
https://github.com/apache/tomcat/pull/673
---
.../apache/tomcat/util/net/AbstractEndpoint.java | 25 +--
.../tomcat/util/net/SSLHostConfigCertificate.java | 29 +-
webapps/docs/changelog.xml | 5
3 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index dfc0eb65f9..09559b4f72 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -408,14 +408,18 @@ public abstract class AbstractEndpoint {
sslHostConfig.setEnabledCiphers(sslUtil.getEnabledCiphers());
}
-SSLContext sslContext;
-try {
-sslContext = sslUtil.createSSLContext(negotiableProtocols);
-} catch (Exception e) {
-throw new IllegalArgumentException(e.getMessage(), e);
+SSLContext sslContext = certificate.getSslContext();
+// Generate the SSLContext from configuration unless (e.g.
embedded) an SSLContext has been provided.
+if (sslContext == null) {
+try {
+sslContext = sslUtil.createSSLContext(negotiableProtocols);
+} catch (Exception e) {
+throw new IllegalArgumentException(e.getMessage(), e);
+}
+
+certificate.setSslContextGenerated(sslContext);
}
-certificate.setSslContext(sslContext);
logCertificate(certificate);
}
}
@@ -616,7 +620,8 @@ public abstract class AbstractEndpoint {
protected void releaseSSLContext(SSLHostConfig sslHostConfig) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates()) {
if (certificate.getSslContext() != null) {
-SSLContext sslContext = certificate.getSslContext();
+// Only release the SSLContext if we generated it.
+SSLContext sslContext = certificate.getSslContextGenerated();
if (sslContext != null) {
sslContext.destroy();
}
@@ -1407,7 +1412,11 @@ public abstract class AbstractEndpoint {
public void unbind() throws Exception {
for (SSLHostConfig sslHostConfig : sslHostConfigs.values()) {
for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates()) {
-certificate.setSslContext(null);
+/*
+ * Only remove any generated SSLContext. If the SSLContext was
provided it is left in place in case the
+ * endpoint is re-started.
+ */
+certificate.setSslContextGenerated(null);
}
}
}
diff --git a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
index 4b7b2a4c70..e50b4b0c5d 100644
--- a/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
+++ b/java/org/apache/tomcat/util/net/SSLHostConfigCertificate.java
@@ -50,10 +50,14 @@ public class SSLHostConfigCertificate implements
Serializable {
// Internal
private ObjectName oname;
-// OpenSSL can handle multiple certs in a single config so the reference to
-// the context is at the virtual host level. JSSE can't so the reference is
-// held here on the certificate.
-private transient volatile SSLContext sslContext;
+/*
+ * OpenSSL can handle multiple certs in a single config so the reference
to the context is at the virtual host
+ * level. JSSE can't so the reference is held here on the certificate.
Typically, the SSLContext is generated from
+ * the configuration but, particularly in embedded scenarios, it can be
provided directly.
+ */
+private transient volatile SSLContext sslContextProvided;
+private transient volatile SSLContext sslContextGenerated;
+
// Common
private final SSLHostConfig sslHostConfig;
@@ -90,12 +94,25 @@ public class SSLHostConfigCertificate implements
Serializable {
public SSLContext getSslContext() {
-return sslContext;
+if (sslContextProvided != null) {
+return sslContextProvided;
+}
+
Re: [PR] Added option to use custom SSLContext [tomcat]
markt-asf commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-1931990842 I have some ideas on how to address this. I might have a fix for this soon that takes account of the lifecycle issues. -- 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] Added option to use custom SSLContext [tomcat]
Hakky54 commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-1931967568 Ah that is pity, I was looking forward to it. You have a better overview of the issues which it can cause to other functionalities. I was not aware of the lifecycle management and only focused on injecting the sslcontext programmatically. If you consider to work on this topic in the future feel free to ping, I still hope it will be available. -- 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 68559] BadRequestException doesn't send back a 400 when using Async servlets
https://bz.apache.org/bugzilla/show_bug.cgi?id=68559 --- Comment #8 from Mark Thomas --- I've been able to look at this some more. Thanks so much for the test case. It really speeds up the process. The processing paths for sync and async are distinct. Currently the error handling in async is handled much further up the stack than sync. That is a factor in why async is more blunt in its error handling. I'm looking to see if I can make the error handling more nuanced for async. -- 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 68449] session.maxInactiveInterval() is not working for SSO Users.
https://bz.apache.org/bugzilla/show_bug.cgi?id=68449 Mark Thomas changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #4 from Mark Thomas --- I have tested the provided reproduction steps with Tomcat 9.0.x and I do not see the behaviour described. Monitoring session TTL via the Manager web application I can see that the call to session.setMaxInactiveInterval() has the expected effect and changes the session TTL. -- 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: [PR] Added option to use custom SSLContext [tomcat]
markt-asf commented on PR #673: URL: https://github.com/apache/tomcat/pull/673#issuecomment-1931686883 I was tempted to merge this but having reviewed the Tomcat code I think this is going to create problems - the main one being that Tomcat clears the SSLContext on Connector.stop() when `bindOnInit` is `false`. I think allowing this is going to create lifecycle management issues. I'm not against a mechanism to allow an SSLContext to be provided directly rather than via the current SSLImplementation but it needs to be one that addresses the Lifecycle issues. -- 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] Added option to use custom SSLContext [tomcat]
markt-asf closed pull request #673: Added option to use custom SSLContext URL: https://github.com/apache/tomcat/pull/673 -- 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: Moving to Tomcat Native 1.3.x
> >> The next 8.5.x and 9.0.x releases would then ship with Tomcat Native > >> 1.3.0 but minimum required/recommended Tomcat Native versions would not > >> change. > > > > I wouldn't bother with 8.5 and 1.3, I'd use 1.2.x until end of 8.5 and the > > put 1.2.x EOL. > > I'm still leaning towards switching 8.5.x to 1.3.0 but if the consensus > is to stcik with the current 1.2.x release I'm fine with that. I'm > mainly trying to avoid another 1.2.x release on top of all the other > releases I am juggling at the moment. I'd produce a last 1.2.x release to clean up/deliver the last changes from that branch to production, then the branch can be "closed". - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PR] Add a fallback when people use Parameters class concurrently, to avoid lost params [tomcat]
markt-asf commented on PR #686: URL: https://github.com/apache/tomcat/pull/686#issuecomment-1931626326 WONTFIX - As per section 2.3.3.4 applications are responsible for accessing the request in a thread safe manner. -- 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] Add a fallback when people use Parameters class concurrently, to avoid lost params [tomcat]
markt-asf closed pull request #686: Add a fallback when people use Parameters class concurrently, to avoid lost params URL: https://github.com/apache/tomcat/pull/686 -- 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 68593] Request Context is replaced after restoreRequest()
https://bz.apache.org/bugzilla/show_bug.cgi?id=68593 Mark Thomas changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |INVALID --- Comment #2 from Mark Thomas --- This report uses both context and content. Given that the report references the restoreRequest() method which doesn't touch the context I am going to assume the references to context are typos for content. That the content is replaced with the content from the original request is how FORM auth is expected to work. I am therefore closing this issue as INVALID. -- 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
