Re: [tomcat] 01/04: Add connection pool to JNDI realm
Am 2020-10-13 um 13:49 schrieb Rémy Maucherat: On Tue, Oct 13, 2020 at 11:33 AM Michael Osipov wrote: Am 2020-10-07 um 22:34 schrieb r...@apache.org: This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch 8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 50de36b7874da98591345e40b374a1e2dd52c188 Author: remm AuthorDate: Thu Jan 30 17:22:51 2020 +0100 Add connection pool to JNDI realm This implements a TODO from the class javadoc header. As described in the javadoc, the idea is to use a pool to avoid blocking on a single connection, which could possibly become a bottleneck in some cases. The message formats need to be kept along with the connection since they are not thread safe. Preserve the default behavior: sync without pooling (using a Lock object which is more flexible). I may backport this since this is limited to the JNDI realm, but only once it is confirmed to be regression free. Tested with ApacheDS but my LDAP skills are very limited. --- java/org/apache/catalina/realm/JNDIRealm.java | 442 - .../apache/catalina/realm/LocalStrings.properties | 1 + test/org/apache/catalina/realm/TestJNDIRealm.java | 7 +- webapps/docs/changelog.xml | 3 + webapps/docs/config/realm.xml | 7 + 5 files changed, 276 insertions(+), 184 deletions(-) Salut Rémy, this is a very very nice improvement to the matter and I gave your idea a spin my public Active Directory realm. Based on my tests with AD I see room for improvement: (Note that I don't use the JNDIRealm because because is it too generic and usable for me) Ok, I only tested this with a local ldap, so not much. I verified it was pooling connections. * You might want to consider to introduce a maxIdleTime to avoid stale connections, e.g., AD has default value of 15 minutes. Yep, I had had several RSTs resulting in 401s Oops. So I don't think adding something like this helps since there could be plenty of issues besides a timeout. Basically it's supposed to retry instead when something fails. Can you give me a stack trace to show what's wrong ? I consider it cheaper to test for a timeout and close actively rather than recover from a resetted connection. Here is a strack trace for concurrency of 4 (with a pool of max 8). Compare the timestamp of the first line and the subsequent ones: 2020-10-12T22:55:47 FEIN [https-openssl-apr-8444-exec-8] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.release Releasing directory server connection to pool 2020-10-12T23:13:06 FEIN [https-openssl-apr-8444-exec-5] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.acquire Acquiring directory server connection from pool 2020-10-12T23:13:06 FEIN [https-openssl-apr-8444-exec-5] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.validate Validating directory server connection from pool 2020-10-12T23:13:06 SCHWERWIEGEND [https-openssl-apr-8444-exec-5] net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.validate Exception validating directory server connection javax.naming.CommunicationException: Connection reset [Root exception is java.net.SocketException: Connection reset]; remaining name '' at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2030) at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1872) at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1797) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:296) at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.validate(ActiveDirectoryRealm.java:316) at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.acquire(ActiveDirectoryRealm.java:285) at net.sf.michaelo.tomcat.realm.ActiveDirectoryRealm.getPrincipal(ActiveDirectoryRealm.java:244) at org.apache.catalina.realm.RealmBase.authenticate(RealmBase.java:501) at net.sf.michaelo.tomcat.authenticator.SpnegoAuthenticator.doAuthenticate(SpnegoAuthenticator.java:165) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:633) at org.apache.catalina.valves.rewrite.RewriteValve.invoke(RewriteValve.java:571) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:690) at org.apache.catalina.core.StandardEngineValve.invoke
[DISCUSS] Deprecate and remove RealmBase#stripRealmForGss
Folks, I'd like to propose to get rid of that config option in 10 and deprecate in previous versions for the following reasons: * It suffers from abstraction: It assumes that the GSS name is always email style w/o checking its OID * The realm part, if any, is an integeral part of the principal. Much like with an email address' domain. You wouldn't stip here too, would you? * It is a surprise for clients having the princippal mutilated by default. I trip over and over again this when I set up UserDatabaseRealms for testing purposes I wonder why michae...@example.com does not work. * In a multi realm environment, it is perfectly fine and valid to have user1@REALMA and user1@REALMB. These are distinct principals, but treated by RealmBase equally, this has implications. * Finally, when doing cert-based auth in an AD envinronment, is it pretty common to extract the msUPN name from the cert's SAN which is almost always email address (enteprise principal) which would end up in michael.osipov, but where is the rest?! Thoughts? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] 01/04: Add connection pool to JNDI realm
Am 2020-10-07 um 22:34 schrieb r...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 50de36b7874da98591345e40b374a1e2dd52c188
Author: remm
AuthorDate: Thu Jan 30 17:22:51 2020 +0100
Add connection pool to JNDI realm
This implements a TODO from the class javadoc header.
As described in the javadoc, the idea is to use a pool to avoid blocking
on a single connection, which could possibly become a bottleneck in some
cases. The message formats need to be kept along with the connection
since they are not thread safe.
Preserve the default behavior: sync without pooling (using a Lock object
which is more flexible).
I may backport this since this is limited to the JNDI realm, but only
once it is confirmed to be regression free. Tested with ApacheDS but my
LDAP skills are very limited.
---
java/org/apache/catalina/realm/JNDIRealm.java | 442 -
.../apache/catalina/realm/LocalStrings.properties | 1 +
test/org/apache/catalina/realm/TestJNDIRealm.java | 7 +-
webapps/docs/changelog.xml | 3 +
webapps/docs/config/realm.xml | 7 +
5 files changed, 276 insertions(+), 184 deletions(-)
Salut Rémy,
this is a very very nice improvement to the matter and I gave your idea
a spin my public Active Directory realm. Based on my tests with AD I see
room for improvement: (Note that I don't use the JNDIRealm because
because is it too generic and usable for me)
* You might want to consider to introduce a maxIdleTime to avoid stale
connections, e.g., AD has default value of 15 minutes. Yep, I had had
several RSTs resulting in 401s
* Validating connections optionally might be a good option to detect
stale connections or broken ones ny networks issues. This works for me
very fast:
protected boolean validate(DirContextConnection connection) {
if (logger.isDebugEnabled())
logger.debug(sm.getString("activeDirectoryRealm.validate"));
SearchControls controls = new SearchControls();
controls.setSearchScope(SearchControls.OBJECT_SCOPE);
controls.setCountLimit(1);
controls.setReturningAttributes(new String[] { "objectClass" });
controls.setTimeLimit(500);
try {
NamingEnumeration results =
connection.context.search("", "objectclass=*",
controls);
if (results.hasMore()) {
close(results);
return true;
}
} catch (NamingException e) {
logger.error(sm.getString("activeDirectoryRealm.validate.namingException"), e);
return false;
}
return false;
}
I do this in the acquire() method
* The acquire(), authenticate(), fail, close(), authenticate(),
release() is brittle and proved to fail here. I have a curl script which
does 4 requests in parallel and 1200 requests in total. Pool size is 8.
4 connections in the pool. Rest for 16 minutes, connections are broken
now. Start requests. authenticate() will fail twice because top two
acquired connections from pool are broken. Requests end with 401. I'd
prefer to to modify acquire() is such a fashion:
protected DirContextConnection acquire() {
if (logger.isDebugEnabled())
logger.debug(sm.getString("activeDirectoryRealm.acquire"));
DirContextConnection connection = null;
while (connection == null) {
connection = connectionPool.pop();
if (connection != null) {
long idleTime = System.currentTimeMillis() -
connection.lastBorrowTime;
if (idleTime > maxIdleTime) {
if (logger.isDebugEnabled())
logger.debug(sm.getString("activeDirectoryRealm.exceedMaxIdleTime"));
close(connection);
connection = null;
} else {
boolean valid = validate(connection);
if (valid) {
if (logger.isDebugEnabled())
logger.debug(sm.getString("activeDirectoryRealm.reuse"));
} else {
close(connection);
connection =
Re: [VOTE][RESULT] Release Apache Tomcat Native 1.2.25
Am 2020-09-03 um 16:34 schrieb Mark Thomas: The following votes were cast: Binding: +1: markt, mgrigorov, fschumacher +0: schultz The vote therefore passes. I think it is worth noting that there were crashes / unit test failures reported with LibreSSL. This isn't unexpected. There is more work to do for LibreSSL support. Back then, when I discovered the first flaws with LibreSSL, I started going thorugh all ifdefs which disable features with LibreSSL and searching in the Git repo for the proper LibreSSL version. I will publish my findings in an ubrella ticket soon. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.2.25
Am 2020-08-24 um 15:42 schrieb Mark Thomas: On 24/08/2020 12:58, Michael Osipov wrote: Am 2020-08-21 um 20:22 schrieb Mark Thomas: Version 1.2.25 includes the following changes compared to 1.2.24 - Improvements to LibreSSL support - Improvements to HP_UX support Various other fixes and improvements. See the changelog for details. The proposed release artefacts can be found at [1], and the build was done using tag [2]. A bit late, but here are my findings. I am not sure whether they are in Tomcat or libtcnative. I see reliable failures in tests with LibreSSL 2.9.0 and 3.2.1 (master) with libtcnative master and Tomcat master on FreeBSD 12-STABLE and OpenJDK 1.8.0_265. Is that any different with 1.2.24? FWIW, I have tried now 2.9.x, 3.0.x, 3.1.x and 3.2.x (master). All of them crash (JVM crash) TEST-org.apache.tomcat.util.net.TestSSLHostConfigCompat.*.txt. It must be a general problem somewhere. frame #10: 0x000a6e3df807 libtcnative-1.so.0.2.24`Java_org_apache_tomcat_jni_SSLContext_setCertificateRaw(e=0x0008054421e0, o=, ctx=44874834080, javaCert=, javaKey=, idx=0) at sslcontext.c:1192:9 frame #11: 0x000805618587 as well as Stack: [0x7fffdfefe000,0x7fffdfffe000], sp=0x7fffdfffb7c0, free space=1013k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libssl.so.48+0x42b59] SSL_CTX_use_certificate+0x9 C [libtcnative-1.so.0.2.24+0x24807] Java_org_apache_tomcat_jni_SSLContext_setCertificateRaw+0x1d7 j org.apache.tomcat.jni.SSLContext.setCertificateRaw(J[B[BI)Z+0 j org.apache.tomcat.util.net.openssl.OpenSSLContext.addCertificate(Lorg/apache/tomcat/util/net/SSLHostConfigCertificate;)V+214 j org.apache.tomcat.util.net.AprEndpoint.createSSLContext(Lorg/apache/tomcat/util/net/SSLHostConfig;)V+146 j org.apache.tomcat.util.net.AprEndpoint.bind()V+461 j org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup()V+1 M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.2.25
Am 2020-08-24 um 15:42 schrieb Mark Thomas: On 24/08/2020 12:58, Michael Osipov wrote: Am 2020-08-21 um 20:22 schrieb Mark Thomas: Version 1.2.25 includes the following changes compared to 1.2.24 - Improvements to LibreSSL support - Improvements to HP_UX support Various other fixes and improvements. See the changelog for details. The proposed release artefacts can be found at [1], and the build was done using tag [2]. A bit late, but here are my findings. I am not sure whether they are in Tomcat or libtcnative. I see reliable failures in tests with LibreSSL 2.9.0 and 3.2.1 (master) with libtcnative master and Tomcat master on FreeBSD 12-STABLE and OpenJDK 1.8.0_265. Is that any different with 1.2.24? 1.2.24 does not compile at all with LibreSSL unless you perform these steps: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246373#c0 I did that, compiled against 2.9.2 and 3.2.1 (master): Same behavior! This isn't a blocker (critical) for you now? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.2.25
Am 2020-08-21 um 20:22 schrieb Mark Thomas: Version 1.2.25 includes the following changes compared to 1.2.24 - Improvements to LibreSSL support - Improvements to HP_UX support Various other fixes and improvements. See the changelog for details. The proposed release artefacts can be found at [1], and the build was done using tag [2]. A bit late, but here are my findings. I am not sure whether they are in Tomcat or libtcnative. I see reliable failures in tests with LibreSSL 2.9.0 and 3.2.1 (master) with libtcnative master and Tomcat master on FreeBSD 12-STABLE and OpenJDK 1.8.0_265. Please see: http://home.apache.org/~michaelo/tomcat-master-tcnative-master-libressl-2.9.0/ as well as http://home.apache.org/~michaelo/tomcat-master-tcnative-master-libressl-master/. Let me know if you need further information for analysis/fixing. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Tomcat Native 1.2.25
Am 2020-08-20 um 18:30 schrieb Mark Thomas: Hi, It has been a while since 1.2.24 and there are a few fixes in the changelog (mainly for LibreSSL and better support for a range of platforms). With this in mind, I'm currently intending to tag 1.2.25 in ~24 hours Please go ahead. I have started at some point in the parst to go through ifdefs and identify all LibreSSL versions which implement the OpenSSL counterparts. I hope I can pick that up next months. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Extracted CSS styles to external file for better code mainenance
Am 2020-08-16 um 21:58 schrieb Igal Sapir: Michael, On Sun, Aug 16, 2020 at 11:37 AM Michael Osipov wrote: Am 2020-08-16 um 20:05 schrieb isa...@apache.org: This is an automated email from the ASF dual-hosted git repository. isapir pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new 9c5d2e3 Extracted CSS styles to external file for better code mainenance 9c5d2e3 is described below commit 9c5d2e3b633fdb651bc9f11db4aac97ad3ad4df2 Author: Igal Sapir AuthorDate: Sun Aug 16 11:05:05 2020 -0700 Extracted CSS styles to external file for better code mainenance Also replaced gif logo with svg --- java/org/apache/catalina/manager/Constants.java| 79 +- There is a slight problem to that: TOMCAT_CSS is shared throughout the codebase. Do you want to break that up in CSS modules or duplicate code? The new file "manager.css" includes the code from TOMCAT_CSS, which is really just a few lines of CSS [1]. We can certainly add another file with just that but IMO it would be an overkill and would result in an additional unnecessary http request. Accepted! Toda raba! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Extracted CSS styles to external file for better code mainenance
Am 2020-08-16 um 20:05 schrieb isa...@apache.org: This is an automated email from the ASF dual-hosted git repository. isapir pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new 9c5d2e3 Extracted CSS styles to external file for better code mainenance 9c5d2e3 is described below commit 9c5d2e3b633fdb651bc9f11db4aac97ad3ad4df2 Author: Igal Sapir AuthorDate: Sun Aug 16 11:05:05 2020 -0700 Extracted CSS styles to external file for better code mainenance Also replaced gif logo with svg --- java/org/apache/catalina/manager/Constants.java| 79 +- There is a slight problem to that: TOMCAT_CSS is shared throughout the codebase. Do you want to break that up in CSS modules or duplicate code? M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Remove the functional specs from docs webapp
Am 2020-08-11 um 21:04 schrieb Mark Thomas: On 11/08/2020 17:30, Michael Osipov wrote: Am 2020-08-10 um 17:46 schrieb Mark Thomas: Hi all, I'd like to propose removing all the functional spec pages from the documentation web application. +1 Can you list them specifically? I am a bit lost which you exactly mean. Everything under: https://tomcat.apache.org/tomcat-10.0-doc/funcspecs/ Thanks, I hav never seen these pages before. A lot of information would be gone, but I prefer rather no information than outdated -- even worse wrong information. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Improve entity tag handling
Am 2020-08-11 um 18:53 schrieb Mark Thomas:
On 11/08/2020 17:29, Michael Osipov wrote:
Am 2020-08-11 um 16:52 schrieb ma...@apache.org:
commit bef507e1b7ac2eb0ff012d0d40035e218a5839cc
Author: Mark Thomas
AuthorDate: Tue Aug 11 15:27:45 2020 +0100
Improve entity tag handling
@@ -279,6 +280,8 @@ public class DefaultServlet extends HttpServlet {
*/
private boolean allowPartialPut = true;
+ protected boolean useWeakComparisonWithIfMatch = true;
I really must object this. It clearly violates RFC 7232, section 3.1:
Prior to this commit the code did not use a strong comparison for
If-Match contrary to the requirements of RFC 7232.
This commit does not change this behaviour (by default)
This commit adds an option so that RFC 7232 compliant behaviour can be
enabled by those who want it without breaking backwards compatibility
for any users that are reliant on the current, non-compliant behaviour.
An origin server MUST use the strong comparison function when
comparing entity-tags for If-Match...
Even an option for this is wrong. I agree that we cannto produce strong
ETags by default, but it is now better decoupled and a subclass can
handle this. Please retain the semantics as described in RFC 7232.
It isn't possible to retain the semantics of RFC 7232 because Tomcat
prior to this commit did not implement them.
If you look at the code prior to this commit, any "W/" was stripped from
the resource ETag and the ETag values in the If-Match header before
comparison. The result of doing that is that the comparison is
effectively a weak one rather than a strong one.
The option is required to preserve backwards compatibility.
Granted. This ultimately means that Tomcat 10 should remove this cruft
and be RFC-compliant. For previous versions a comment about behavioral
change/deprecation should be added too.
Can we agree on this?
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Improve entity tag handling
Am 2020-08-11 um 16:52 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new bef507e Improve entity tag handling
bef507e is described below
commit bef507e1b7ac2eb0ff012d0d40035e218a5839cc
Author: Mark Thomas
AuthorDate: Tue Aug 11 15:27:45 2020 +0100
Improve entity tag handling
---
conf/web.xml | 8 ++
.../apache/catalina/servlets/DefaultServlet.java | 116 +
.../apache/tomcat/util/http/parser/EntityTag.java | 82
.../TestDefaultServletIfMatchRequests.java | 143 +
webapps/docs/changelog.xml | 7 +
webapps/docs/default-servlet.xml | 8 +-
6 files changed, 284 insertions(+), 80 deletions(-)
diff --git a/conf/web.xml b/conf/web.xml
index a685947..b5e0b30 100644
--- a/conf/web.xml
+++ b/conf/web.xml
@@ -114,6 +114,14 @@
+
+
+
+
+
+
+
+
...
@@ -279,6 +280,8 @@ public class DefaultServlet extends HttpServlet {
*/
private boolean allowPartialPut = true;
+protected boolean useWeakComparisonWithIfMatch = true;
I really must object this. It clearly violates RFC 7232, section 3.1:
An origin server MUST use the strong comparison function when
comparing entity-tags for If-Match...
Even an option for this is wrong. I agree that we cannto produce strong
ETags by default, but it is now better decoupled and a subclass can
handle this. Please retain the semantics as described in RFC 7232.
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Remove the functional specs from docs webapp
Am 2020-08-10 um 17:46 schrieb Mark Thomas: Hi all, I'd like to propose removing all the functional spec pages from the documentation web application. My reasoning for this proposal is, in short, that we aren't using or maintaining these pages. I don't recall any discussion of these docs on the dev list, proposals to change them, proposals for additions etc. There have been changes but going back over the changes from the last 10 years (and there are very few of them) they each appear to be part of a wider global change that is updating something or removing references to a feature that has been removed. Should someone want to revive these pages, or more likely a subset of them, they'll always be in the history. Thoughts? +1 Can you list them specifically? I am a bit lost which you exactly mean. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.57
Am 2020-07-01 um 00:14 schrieb Mark Thomas: The proposed Apache Tomcat 8.5.57 release is now available for voting. The notable changes compared to the 8.5.56 release are: - Implement a significant portion of the TLS environment variables for the rewrite valve. - Reduce memory footprint of closed HTTP/2 streams - Improve parsing of RFC 2109 cookies Along with lots of other bug fixes and improvements. For full details, see the changelog: https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.57/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1274/ The tag is: https://github.com/apache/tomcat/tree/8.5.57 9c649984ef92c2534a734c6584220a9a0c0c3462 The proposed 8.5.57 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.57 Passes smoothly on AdoptOpenJDK 8u252 on FreeBSD 12-STABLE. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
Am 2020-06-16 um 12:09 schrieb Mark Thomas: On 16/06/2020 10:25, Michael Osipov wrote: Am 2020-06-16 um 10:02 schrieb Mark Thomas: All, You may have seen the recent discussions both inside and outside the ASF about the user of "master" as the name of the default git branch. If you haven't, the short version is that the name can be traced back to master/slave and its associations with human slavery. I'd like to propose that the Apache Tomcat project renames the master branch in all of the project repositories. I think there are two front runners for the new name: - main - this looks to be the name GitHub and a number of OSS projects will be switching to - trunk - reflects the Subversion heritage of both the project and the ASF Other options I have seen suggested include "default", "dev", "develop". Other suggestions welcome. Personally, I am leaning towards main as that looks to be the choice of the majority and using the majority choice will make it (a little bit) easier for new community members to find their way around the project. In terms of impact, changing the name is going to break stuff. It is really creating a new branch and deleting the old one. Deleting a branch triggers the automatic closure of github PRs against that branch. However if we create "$new_branch" we can edit the PRs to use "$new_branch" before we delete master. Given the small number of open PRs that is easily done. CI systems will need to be updated (buildbot, gump). That should be relatively simple. Docs will need to be updated (relatively simple). Committers and contributors will rebase any local branches to $new_branch Having thought about what is involved, renaming the default branch doesn't look as problematic as I thought it might be. This looks like something that could be done in around an hour for all our repos. Thoughts? Although on the Git ML this has been discussed that master comes from Master Copy (music, recoding, etc) and is not related to slavery, I prefer the term "main" as many other projects now do. It isn't that clear cut. If you trace it back there are places where branches are referred to as master and slave as well as places where the master record idea is used. Various references can be found in this thread: https://twitter.com/tobie/status/1270290278029631489 Indeed, this one is the worst: https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L290-L291 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Changing the name of the default branch in our git repos
Am 2020-06-16 um 10:02 schrieb Mark Thomas: All, You may have seen the recent discussions both inside and outside the ASF about the user of "master" as the name of the default git branch. If you haven't, the short version is that the name can be traced back to master/slave and its associations with human slavery. I'd like to propose that the Apache Tomcat project renames the master branch in all of the project repositories. I think there are two front runners for the new name: - main - this looks to be the name GitHub and a number of OSS projects will be switching to - trunk - reflects the Subversion heritage of both the project and the ASF Other options I have seen suggested include "default", "dev", "develop". Other suggestions welcome. Personally, I am leaning towards main as that looks to be the choice of the majority and using the majority choice will make it (a little bit) easier for new community members to find their way around the project. In terms of impact, changing the name is going to break stuff. It is really creating a new branch and deleting the old one. Deleting a branch triggers the automatic closure of github PRs against that branch. However if we create "$new_branch" we can edit the PRs to use "$new_branch" before we delete master. Given the small number of open PRs that is easily done. CI systems will need to be updated (buildbot, gump). That should be relatively simple. Docs will need to be updated (relatively simple). Committers and contributors will rebase any local branches to $new_branch Having thought about what is involved, renaming the default branch doesn't look as problematic as I thought it might be. This looks like something that could be done in around an hour for all our repos. Thoughts? Although on the Git ML this has been discussed that master comes from Master Copy (music, recoding, etc) and is not related to slavery, I prefer the term "main" as many other projects now do. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Building mod_jk for Windows
Am 2020-06-13 um 19:56 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I see Mladen has gone crazy updating mod_jk for IIS. The build process looks fairly straightforward in a way that isn't so straightforward for e.g. libtcnative. I suspect most of it is the work that has gone into his "Custom Microsoft Compiler Toolkit Compilation" to make sure it has everything it needs. I wonder if this could be Dockerized to make it even easier for just about anyone to perform a Windows build of mod_jk. Even better, perhaps a similar toolchain could be used to build libtcnative as well. Does anyone have extensive Docker experience? I certainly do not... I prefer CMake for truly portable builds. Due to my recent work on libtcnative I have noticed that both the autoconf files als well as Makefiles have a lot of ancient cruft. I'd be happy to invoke just CMake and just make on any platform. That is a long-term goal for me with tcnative. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Java library bug in JCEKS keystore loader
Am 2020-06-12 um 23:54 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I've been writing a Java-based certification-expiration checking utility that can handle all kinds of file formats like PEM and the various keystore formats supported by the JVM. Since it's not possible to tell what type of keystore is being loaded without writing a bunch of magic-checking code or implementing an ASN.1 parser (no thank you), I simply try all keystore types until I find one that works. I'm using a rewindable InputStream which works well . there is no need to, use Apache Directory Kerby ASN.1 module. I use it too and it works very well for my certiticate tasks at work. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Maven uploads and hashes
I have just released Maven Resolver Ant Tasks 1.2.1. Should be soon on Central. SHA-2 is up next. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Maven uploads and hashes
Am 2020-05-29 um 20:55 schrieb Mark Thomas: On 29/05/2020 19:42, Michael Osipov wrote: Am 2020-05-29 um 16:48 schrieb Mark Thomas: On 29/05/2020 15:23, Michael Osipov wrote: Am 2020-05-29 um 14:05 schrieb Mark Thomas: Hi, Currently we use the (very old) Maven Ant Tasks to upload files to Nexus. This has a hard-coded feature that adds MD5 and SHA-1 hashes for every uploaded file. It also adds hashes for .asc files. I investigated manually adding .sha256 and .sha512 files. This works, bu the upload process still adds .md5 and .sha1 files for the .sha256 and .sha512 files. This is workable but not ideal. I am currently investigating the possibility of switching to the newer Maven Resolver Ant Tasks. This is a work in progress. It has a LOT more dependencies and the default behaviour is unchanged. I am currently looking at the source to see if the behaviour could be configured. In amongst all of this I had a thought. What if we just made a binary patch to the Maven Ant Tasks to switch it from creating MD5 and SHA-1 hashes to creating SHA-256 and SHA-512 hashes? At first glance this looks to be a small tweak to a single class that should be doable with BCEL (a bit like a very targetted Jakarta Migration Tool). Is this a terrible idea? I wanted to get some feedback on this while I continued to look at the Maven Resolver Ant Tasks. I need to add a few lines here since I maintain Maven Resolver these days. So no need to patch anything, we can work upstream. We have/had these requests recently for SHA-2 family of hashes. What hold me off is that Nexus before 2.14.18 did reject SHA-2 hashes for Central. Moreover, you cannot omit MD5 and SHA-1 for Central because they are mandatory, you won't pass evaluation on repository.a.o. Regarding the JARs, I do use Maven Resolver Ant Tasks too at work to customize Tomcat distributin for several OSes and there is a single JAR you can use: https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-ant-tasks/1.2.0/maven-resolver-ant-tasks-1.2.0-uber.jar Ah. I didn't see the uber JAR. That helps a lot. I would not recommend committing it due to the size, but simply require it to be in ~/.ant or in ANT_HOME. Agreed. JARs don't belong in source repos. We can download it on demand. When Aether has been adopted from Eclipse, license has also changed from EPL to AL. I see no issues here. Great. WDYT? Cool. I think we have a possible solution here. 1. Switch to using the maven-resolver-ant-tasks with the uber JAR. This gives us the immediate benefit that we won't be generating .asc.md5 and .asc.sha1 files. I pretty much have this ready to go. I just need to tweak it to use the uber JAR. 2. Update to a newer version of maven-resolver-ant-tasks when a version that adds .sha256 and .sha512 is available. I'd be fine if it added .md5, .sha1, .sha256 and .sha512 Correct. I have recently updated Resolver. Ant Tasks need some love to perform again. This is the next point on my list. As soon as a new Ant Tasks release is out, I will head over to Resolver master and provide you a branch with a tentative fix for the SHA-2 issue. Acceptable? Perfect. Sounds great. I'm just about to update master to Maven Resolver Ant Tasks in preparation. I'll back-port as well. * Clone MRESOLVER, switch to MRESOLVER-56, install locally * Clone MRESOLVER AT, update MRESOLVER to 1.4.3-SNAPSHOT, install locally * Use the SNAPSHOT version of the Über JAR for your tests I have built Maven 3.7.0-SNAPSHOT and was able to upload checksums to repository.apache.org. Michael PS: This is all WIP, comments welcome! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Maven uploads and hashes
Am 2020-05-29 um 16:48 schrieb Mark Thomas: On 29/05/2020 15:23, Michael Osipov wrote: Am 2020-05-29 um 14:05 schrieb Mark Thomas: Hi, Currently we use the (very old) Maven Ant Tasks to upload files to Nexus. This has a hard-coded feature that adds MD5 and SHA-1 hashes for every uploaded file. It also adds hashes for .asc files. I investigated manually adding .sha256 and .sha512 files. This works, bu the upload process still adds .md5 and .sha1 files for the .sha256 and .sha512 files. This is workable but not ideal. I am currently investigating the possibility of switching to the newer Maven Resolver Ant Tasks. This is a work in progress. It has a LOT more dependencies and the default behaviour is unchanged. I am currently looking at the source to see if the behaviour could be configured. In amongst all of this I had a thought. What if we just made a binary patch to the Maven Ant Tasks to switch it from creating MD5 and SHA-1 hashes to creating SHA-256 and SHA-512 hashes? At first glance this looks to be a small tweak to a single class that should be doable with BCEL (a bit like a very targetted Jakarta Migration Tool). Is this a terrible idea? I wanted to get some feedback on this while I continued to look at the Maven Resolver Ant Tasks. I need to add a few lines here since I maintain Maven Resolver these days. So no need to patch anything, we can work upstream. We have/had these requests recently for SHA-2 family of hashes. What hold me off is that Nexus before 2.14.18 did reject SHA-2 hashes for Central. Moreover, you cannot omit MD5 and SHA-1 for Central because they are mandatory, you won't pass evaluation on repository.a.o. Regarding the JARs, I do use Maven Resolver Ant Tasks too at work to customize Tomcat distributin for several OSes and there is a single JAR you can use: https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-ant-tasks/1.2.0/maven-resolver-ant-tasks-1.2.0-uber.jar Ah. I didn't see the uber JAR. That helps a lot. I would not recommend committing it due to the size, but simply require it to be in ~/.ant or in ANT_HOME. Agreed. JARs don't belong in source repos. We can download it on demand. When Aether has been adopted from Eclipse, license has also changed from EPL to AL. I see no issues here. Great. WDYT? Cool. I think we have a possible solution here. 1. Switch to using the maven-resolver-ant-tasks with the uber JAR. This gives us the immediate benefit that we won't be generating .asc.md5 and .asc.sha1 files. I pretty much have this ready to go. I just need to tweak it to use the uber JAR. 2. Update to a newer version of maven-resolver-ant-tasks when a version that adds .sha256 and .sha512 is available. I'd be fine if it added .md5, .sha1, .sha256 and .sha512 Correct. I have recently updated Resolver. Ant Tasks need some love to perform again. This is the next point on my list. As soon as a new Ant Tasks release is out, I will head over to Resolver master and provide you a branch with a tentative fix for the SHA-2 issue. Acceptable? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Maven uploads and hashes
Am 2020-05-29 um 14:05 schrieb Mark Thomas: Hi, Currently we use the (very old) Maven Ant Tasks to upload files to Nexus. This has a hard-coded feature that adds MD5 and SHA-1 hashes for every uploaded file. It also adds hashes for .asc files. I investigated manually adding .sha256 and .sha512 files. This works, bu the upload process still adds .md5 and .sha1 files for the .sha256 and .sha512 files. This is workable but not ideal. I am currently investigating the possibility of switching to the newer Maven Resolver Ant Tasks. This is a work in progress. It has a LOT more dependencies and the default behaviour is unchanged. I am currently looking at the source to see if the behaviour could be configured. In amongst all of this I had a thought. What if we just made a binary patch to the Maven Ant Tasks to switch it from creating MD5 and SHA-1 hashes to creating SHA-256 and SHA-512 hashes? At first glance this looks to be a small tweak to a single class that should be doable with BCEL (a bit like a very targetted Jakarta Migration Tool). Is this a terrible idea? I wanted to get some feedback on this while I continued to look at the Maven Resolver Ant Tasks. I need to add a few lines here since I maintain Maven Resolver these days. So no need to patch anything, we can work upstream. We have/had these requests recently for SHA-2 family of hashes. What hold me off is that Nexus before 2.14.18 did reject SHA-2 hashes for Central. Moreover, you cannot omit MD5 and SHA-1 for Central because they are mandatory, you won't pass evaluation on repository.a.o. Regarding the JARs, I do use Maven Resolver Ant Tasks too at work to customize Tomcat distributin for several OSes and there is a single JAR you can use: https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-ant-tasks/1.2.0/maven-resolver-ant-tasks-1.2.0-uber.jar I would not recommend committing it due to the size, but simply require it to be in ~/.ant or in ANT_HOME. When Aether has been adopted from Eclipse, license has also changed from EPL to AL. I see no issues here. WDYT? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Add a constant for invalid URI
Am 2020-05-13 um 11:47 schrieb Rémy Maucherat:
On Wed, May 13, 2020 at 11:30 AM Michael Osipov wrote:
Am 2020-05-13 um 11:18 schrieb Rémy Maucherat:
On Wed, May 13, 2020 at 11:08 AM Michael Osipov
wrote:
Am 2020-05-13 um 09:45 schrieb r...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new f34dd07 Add a constant for invalid URI
f34dd07 is described below
commit f34dd072d189183cbe152135d0a6b88e0a13315b
Author: remm
AuthorDate: Wed May 13 09:45:03 2020 +0200
Add a constant for invalid URI
Add a space to it to make the code look cleaner.
---
java/org/apache/catalina/connector/CoyoteAdapter.java | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index ab113a7..98a33e8 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -72,6 +72,8 @@ public class CoyoteAdapter implements Adapter {
System.getProperty("java.vm.vendor") + "/" +
System.getProperty("java.runtime.version") + ")";
+private static final String INVALID_URI = "Invalid URI ";
+
private static final EnumSet SSL_ONLY =
EnumSet.of(SessionTrackingMode.SSL);
@@ -610,7 +612,7 @@ public class CoyoteAdapter implements Adapter {
connector.getService().getContainer().logAccess(request, response, 0,
true);
return false;
} else {
-response.sendError(400, "Invalid URI");
+response.sendError(400, INVALID_URI);
}
}
@@ -628,7 +630,7 @@ public class CoyoteAdapter implements Adapter {
try {
req.getURLDecoder().convert(decodedURI.getByteChunk(),
connector.getEncodedSolidusHandlingInternal());
} catch (IOException ioe) {
-response.sendError(400, "Invalid URI: " +
ioe.getMessage());
+response.sendError(400, INVALID_URI +
ioe.getMessage());
}
// Normalization
if (normalize(req.decodedURI(),
connector.getAllowBackslash())) {
@@ -638,7 +640,7 @@ public class CoyoteAdapter implements Adapter {
// Therefore it is not necessary to check that the
URI
remains
// normalized after character decoding
} else {
-response.sendError(400, "Invalid URI");
+response.sendError(400, INVALID_URI);
}
} else {
/* The URI is chars or String, and has been sent using
an
in-memory
This change is complete: You have have a trailing 0x20 after the message
and in the case of IOE#getMessage() the colon is gone. Please rework.
What is the big issue ? This is just a string that goes in a HTML that
nobody ever sees [as the URI is invalid, this is not a real client,
simply
a hack attempt], I preferred to simplify a bit since the extra space is
not
a problem and the colon is cosmetic. I can revert this is you decide to
veto it.
If no one ever sees why to write a message at all? Those are just wasted
bytes, aren't they?
It's hard to anticipate which error messages are actually seen, so it's
better to keep them. Although I believe no actual client will see it, I
will not remove this one since the amount saved is zero. Just in case.
I am still trying to find ways to change the Connector situation and am
looking at these classes. If you don't like the change, you should veto and
I will revert no questions asked.
Kindly do so.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Add a constant for invalid URI
Am 2020-05-13 um 11:18 schrieb Rémy Maucherat:
On Wed, May 13, 2020 at 11:08 AM Michael Osipov wrote:
Am 2020-05-13 um 09:45 schrieb r...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new f34dd07 Add a constant for invalid URI
f34dd07 is described below
commit f34dd072d189183cbe152135d0a6b88e0a13315b
Author: remm
AuthorDate: Wed May 13 09:45:03 2020 +0200
Add a constant for invalid URI
Add a space to it to make the code look cleaner.
---
java/org/apache/catalina/connector/CoyoteAdapter.java | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index ab113a7..98a33e8 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -72,6 +72,8 @@ public class CoyoteAdapter implements Adapter {
System.getProperty("java.vm.vendor") + "/" +
System.getProperty("java.runtime.version") + ")";
+private static final String INVALID_URI = "Invalid URI ";
+
private static final EnumSet SSL_ONLY =
EnumSet.of(SessionTrackingMode.SSL);
@@ -610,7 +612,7 @@ public class CoyoteAdapter implements Adapter {
connector.getService().getContainer().logAccess(request, response, 0,
true);
return false;
} else {
-response.sendError(400, "Invalid URI");
+response.sendError(400, INVALID_URI);
}
}
@@ -628,7 +630,7 @@ public class CoyoteAdapter implements Adapter {
try {
req.getURLDecoder().convert(decodedURI.getByteChunk(),
connector.getEncodedSolidusHandlingInternal());
} catch (IOException ioe) {
-response.sendError(400, "Invalid URI: " +
ioe.getMessage());
+response.sendError(400, INVALID_URI + ioe.getMessage());
}
// Normalization
if (normalize(req.decodedURI(),
connector.getAllowBackslash())) {
@@ -638,7 +640,7 @@ public class CoyoteAdapter implements Adapter {
// Therefore it is not necessary to check that the URI
remains
// normalized after character decoding
} else {
-response.sendError(400, "Invalid URI");
+response.sendError(400, INVALID_URI);
}
} else {
/* The URI is chars or String, and has been sent using an
in-memory
This change is complete: You have have a trailing 0x20 after the message
and in the case of IOE#getMessage() the colon is gone. Please rework.
What is the big issue ? This is just a string that goes in a HTML that
nobody ever sees [as the URI is invalid, this is not a real client, simply
a hack attempt], I preferred to simplify a bit since the extra space is not
a problem and the colon is cosmetic. I can revert this is you decide to
veto it.
If no one ever sees why to write a message at all? Those are just wasted
bytes, aren't they?
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Add a constant for invalid URI
Am 2020-05-13 um 09:45 schrieb r...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new f34dd07 Add a constant for invalid URI
f34dd07 is described below
commit f34dd072d189183cbe152135d0a6b88e0a13315b
Author: remm
AuthorDate: Wed May 13 09:45:03 2020 +0200
Add a constant for invalid URI
Add a space to it to make the code look cleaner.
---
java/org/apache/catalina/connector/CoyoteAdapter.java | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/connector/CoyoteAdapter.java
b/java/org/apache/catalina/connector/CoyoteAdapter.java
index ab113a7..98a33e8 100644
--- a/java/org/apache/catalina/connector/CoyoteAdapter.java
+++ b/java/org/apache/catalina/connector/CoyoteAdapter.java
@@ -72,6 +72,8 @@ public class CoyoteAdapter implements Adapter {
System.getProperty("java.vm.vendor") + "/" +
System.getProperty("java.runtime.version") + ")";
+private static final String INVALID_URI = "Invalid URI ";
+
private static final EnumSet SSL_ONLY =
EnumSet.of(SessionTrackingMode.SSL);
@@ -610,7 +612,7 @@ public class CoyoteAdapter implements Adapter {
connector.getService().getContainer().logAccess(request,
response, 0, true);
return false;
} else {
-response.sendError(400, "Invalid URI");
+response.sendError(400, INVALID_URI);
}
}
@@ -628,7 +630,7 @@ public class CoyoteAdapter implements Adapter {
try {
req.getURLDecoder().convert(decodedURI.getByteChunk(),
connector.getEncodedSolidusHandlingInternal());
} catch (IOException ioe) {
-response.sendError(400, "Invalid URI: " + ioe.getMessage());
+response.sendError(400, INVALID_URI + ioe.getMessage());
}
// Normalization
if (normalize(req.decodedURI(), connector.getAllowBackslash())) {
@@ -638,7 +640,7 @@ public class CoyoteAdapter implements Adapter {
// Therefore it is not necessary to check that the URI remains
// normalized after character decoding
} else {
-response.sendError(400, "Invalid URI");
+response.sendError(400, INVALID_URI);
}
} else {
/* The URI is chars or String, and has been sent using an
in-memory
This change is complete: You have have a trailing 0x20 after the message
and in the case of IOE#getMessage() the colon is gone. Please rework.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Dropping reason phrase in WebDavServlet
Am 2020-04-29 um 18:51 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 4/28/20 18:06, Michael Osipov wrote: Am 2020-04-20 um 10:25 schrieb Mark Thomas: On 18/04/2020 21:19, Michael Osipov wrote: Folks, the WebDAV servlet still sends a reason phrase on multistatus (207).I'd like to drop it in master and 9.0.x. It is inconsistent with the behavior with these versions. Any objections/opinions on dropping it? I agree it is inconsistent and I'm generally in favour of anything that improves consistentcy, simplifies, etc. RFC 4918 (WebDAV) references RFC 2616 (HTTP/1.1) where the language is slightly less strong (the client is "not required" to examine it) than RFC 7230 (the client SHOULD ignore it). However, even in RFC 2616 an empty reason phrase is valid. So I think the specs support this change. WebDAV clients, particularly the Microsoft implementations, can have very specific expectations about server behaviour that are not required by the RFC. I think it would be prudent to at least test this change to the WebDAV server implementation with the current Microsoft WebDAV client implementations before rolling it out. Finally dropped locally. Tested with CarotDAV, WinSCP and Windows WebDAV Mini Redirector (Windows Explorer DAV Client) set with anonymous and SPNEGO authenication. Works like before (with reason phrase). I will go ahead and apply the change to master and 9.0.x. 8.5.x disables the reason phrase by default. Shall this applies to it as well? Any objections? Seeing how well-received the original change was (drop reason phrase), perhaps we should limit this to master and not back-port to 9.0, etc. I understand your concerns. Please consider that 9.0.x doesn't send the phrase and doesn't allow to enable it. I think it was an oversight that this one wasn't dropped earlier. I won't back port this to 8.5.x and 7.0.x. Let's keep it in 9.0.x and see whether we receive complains. Is that acceptable? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Dropping reason phrase in WebDavServlet
Am 2020-04-20 um 10:25 schrieb Mark Thomas: On 18/04/2020 21:19, Michael Osipov wrote: Folks, the WebDAV servlet still sends a reason phrase on multistatus (207).I'd like to drop it in master and 9.0.x. It is inconsistent with the behavior with these versions. Any objections/opinions on dropping it? I agree it is inconsistent and I'm generally in favour of anything that improves consistentcy, simplifies, etc. RFC 4918 (WebDAV) references RFC 2616 (HTTP/1.1) where the language is slightly less strong (the client is "not required" to examine it) than RFC 7230 (the client SHOULD ignore it). However, even in RFC 2616 an empty reason phrase is valid. So I think the specs support this change. WebDAV clients, particularly the Microsoft implementations, can have very specific expectations about server behaviour that are not required by the RFC. I think it would be prudent to at least test this change to the WebDAV server implementation with the current Microsoft WebDAV client implementations before rolling it out. Finally dropped locally. Tested with CarotDAV, WinSCP and Windows WebDAV Mini Redirector (Windows Explorer DAV Client) set with anonymous and SPNEGO authenication. Works like before (with reason phrase). I will go ahead and apply the change to master and 9.0.x. 8.5.x disables the reason phrase by default. Shall this applies to it as well? Any objections? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Position on failing tests with vendor-modified OpenSSL packages
Am 2020-04-24 um 01:45 schrieb Michael Osipov: Folks, I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are modified which make several tests fail. See an excerpt here [1]. To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all tests pass, so other must have modified OpenSSL. What is our position in terms of support/testing for modified OpenSSL packages from OS vendors? Should we add a big fat warning somewhere? Add this to tcnative README that we test/recommend upstream only? [1] http://home.apache.org/~michaelo/issues/openssl-tests/ I have now managed to installed OpenSSL 1.1.1 from OS vendor. It contains modifications too: http://home.apache.org/~michaelo/issues/openssl-1.1.1-tests/hpux/ M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.2.24
Am 2020-04-24 um 22:10 schrieb Mark Thomas: Version 1.2.24 includes the following changes compared to 1.2.23 - Various improvements to the build process related to OpenSSL - Windows binaries built with OpenSSL 1.1.1g Various other fixes and improvements. See the changelog for details. The proposed release artefacts can be found at [1], and the build was done using tag [2]. The Apache Tomcat Native 1.2.24 release is [ ] Stable, go ahead and release Stable for me. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Introduce tcn_get_thread_id(void) to reduce code duplication
Am 2020-04-24 um 18:23 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 4/23/20 18:42, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/master by this push: new f95f531 Introduce tcn_get_thread_id(void) to reduce code duplication f95f531 is described below commit f95f531e98278cc7555367084b967e3550734559 Author: Michael Osipov AuthorDate: Thu Apr 23 18:52:44 2020 +0200 Introduce tcn_get_thread_id(void) to reduce code duplication At two spots (ssl.c and thread.c) we need to obtain the native thread id. This has been done with two different approaches. Move out to tcn_get_thread(void) which uses the previous ssl_thread_id(void) implementation while the previous functions delegate to the new one. apr_os_thread_current(void) is not used anymore which does internally the same thing as ssl_thread_id(void) was doing. Also add properly #ifdefs for Windows and macOS for function prototype includes. --- native/include/tcn.h | 1 + native/src/jnilib.c | 45 +++ native/src/ssl.c | 33 +--- native/src/thread.c | 3 ++- xdocs/miscellaneous/changelog.xml | 5 - 5 files changed, 53 insertions(+), 34 deletions(-) diff --git a/native/include/tcn.h b/native/include/tcn.h index 2b2ae59..d2f316b 100644 --- a/native/include/tcn.h +++ b/native/include/tcn.h @@ -175,6 +175,7 @@ char *tcn_strdup(JNIEnv *, jstring); char *tcn_pstrdup(JNIEnv *, jstring, apr_pool_t *); apr_status_t tcn_load_finfo_class(JNIEnv *, jclass); apr_status_t tcn_load_ainfo_class(JNIEnv *, jclass); +unsigned long tcn_get_thread_id(void); #define J2S(V) c##V #define J2L(V) p##V diff --git a/native/src/jnilib.c b/native/src/jnilib.c index dae3ade..e88d4d5 100644 --- a/native/src/jnilib.c +++ b/native/src/jnilib.c @@ -23,6 +23,22 @@ #include "tcn_version.h" +#ifdef WIN32 +#include +#endif + +#ifdef DARWIN +#include +#endif + +#ifdef __FreeBSD__ +#include +#endif + +#ifdef __linux__ +#include +#endif + #ifdef TCN_DO_STATISTICS extern void sp_poll_dump_statistics(); extern void sp_network_dump_statistics(); @@ -481,3 +497,32 @@ jint tcn_get_java_env(JNIEnv **env) } return JNI_OK; } + +unsigned long tcn_get_thread_id(void) Why not simple call apr_os_thread_current() instead of writing a new function? Or is the intention to get away from using APR? Here is the difference between pthread_self() and OS-specific calls: FreeBSD: osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master *%=) $ uname -a FreeBSD deblndw011x.ad001.siemens.net 12.1-STABLE osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master *%=) $ # pthread_self() osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 34381534464 osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 34381534464 osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 34381534464 $ # pthread_getthreadid_np() on FreeBSD osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master %=) $ make -C native/ osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master %=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 100654 osipovmi@deblndw011x:~/var/Projekte/tomcat-native (master %=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 100839 HP-UX: osipovmi@deblndw024v:~/tomcat-native (master *%=) $ uname -a HP-UX deblndw0 B.11.31 U ia64 HP-UX osipovmi@deblndw024v:~/tomcat-native (master *%=) $ # pthread_self() only osipovmi@deblndw024v:~/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 1 osipovmi@deblndw024v:~/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 1 GNU/Linux: osipovmi@deblndw012x: ~/tomcat-native (master *%=) $ uname -a Linux deblndw012x.ad001.siemens.net 3.10.0-1127.el7.x86_64 #1 SMP Tue Feb 18 16:39:12 EST 2020 x86_64 x86_64 x86_64 GNU/Linux $ # pthread_self() osipovmi@deblndw012x: ~/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 140074735822592 osipovmi@deblndw012x: ~/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 139635928618752 osipovmi@deblndw012x: ~/tomcat-native (master *%=) $ java -cp dist/classes/java:. -Djava.library.path=native/.libs TcnativeTest Thread Id: 139627128493824 osipovmi@deblndw012x: ~/tom
Re: [tomcat-native] branch master updated: Introduce tcn_get_thread_id(void) to reduce code duplication
Am 2020-04-24 um 18:23 schrieb Christopher Schultz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 4/23/20 18:42, micha...@apache.org wrote:
This is an automated email from the ASF dual-hosted git
repository.
michaelo pushed a commit to branch master in repository
https://gitbox.apache.org/repos/asf/tomcat-native.git
The following commit(s) were added to refs/heads/master by this
push: new f95f531 Introduce tcn_get_thread_id(void) to reduce code
duplication f95f531 is described below
commit f95f531e98278cc7555367084b967e3550734559 Author: Michael
Osipov AuthorDate: Thu Apr 23 18:52:44 2020
+0200
Introduce tcn_get_thread_id(void) to reduce code duplication
At two spots (ssl.c and thread.c) we need to obtain the native
thread id. This has been done with two different approaches. Move
out to tcn_get_thread(void) which uses the previous
ssl_thread_id(void) implementation while the previous functions
delegate to the new one. apr_os_thread_current(void) is not used
anymore which does internally the same thing as
ssl_thread_id(void) was doing.
Also add properly #ifdefs for Windows and macOS for function
prototype includes. --- native/include/tcn.h | 1 +
native/src/jnilib.c | 45
+++ native/src/ssl.c
| 33 +--- native/src/thread.c
| 3 ++- xdocs/miscellaneous/changelog.xml | 5 - 5 files
changed, 53 insertions(+), 34 deletions(-)
diff --git a/native/include/tcn.h b/native/include/tcn.h index
2b2ae59..d2f316b 100644 --- a/native/include/tcn.h +++
b/native/include/tcn.h @@ -175,6 +175,7 @@ char
*tcn_strdup(JNIEnv *, jstring); char *tcn_pstrdup(JNIEnv
*, jstring, apr_pool_t *); apr_status_t
tcn_load_finfo_class(JNIEnv *, jclass); apr_status_t
tcn_load_ainfo_class(JNIEnv *, jclass); +unsigned long
tcn_get_thread_id(void);
#define J2S(V) c##V #define J2L(V) p##V diff --git
a/native/src/jnilib.c b/native/src/jnilib.c index dae3ade..e88d4d5
100644 --- a/native/src/jnilib.c +++ b/native/src/jnilib.c @@ -23,6
+23,22 @@
#include "tcn_version.h"
+#ifdef WIN32 +#include +#endif + +#ifdef DARWIN
+#include +#endif + +#ifdef __FreeBSD__ +#include
+#endif + +#ifdef __linux__ +#include
+#endif + #ifdef TCN_DO_STATISTICS extern void
sp_poll_dump_statistics(); extern void
sp_network_dump_statistics(); @@ -481,3 +497,32 @@ jint
tcn_get_java_env(JNIEnv **env) } return JNI_OK; } + +unsigned long
tcn_get_thread_id(void)
Why not simple call apr_os_thread_current() instead of writing a new
function? Or is the intention to get away from using APR?
There are several reasons here. Let me go in detail:
* Since we'd like to reduce the dependecy on libapr in the long run,
this is a small preparation.
* When you take a look at how apr_os_thread_current(void) is implemented
you will see that is is mediocre, on Unix(-like) it calls pthread_self().
Our approach for ssl_thread_id(void) is been better than the APR
counterpart. I have done a research why pthread_self() isn't enough and
an overwhelming amount of voices says that pthread_self() gives very
little information, but the thread pointer which is not the thread id.
So this is the last resort, but not a real solution.
+{ +/* OpenSSL needs this to return an unsigned long. On
OS/390, the pthread + * id is a structure twice that big. Use
the TCB pointer instead as a + * unique unsigned long. +
*/ +#ifdef __MVS__ +struct PSA { +char unmapped[540]; +
unsigned long PSATOLD; +} *psaptr = 0; + +return
psaptr->PSATOLD;
I think we might want to put the above #ifdef as the LAST one in the
list. I think if we can call pthread_self, we should, even if this
other technique will work.
I do not fully understand this. Should the test for z/OS happen before
the generic code? The code comes from here [1].
+#elif defined(WIN32) +return (unsigned
long)GetCurrentThreadId(); +#elif defined(DARWIN) +uint64_t
tid; +pthread_threadid_np(NULL, ); +return (unsigned
long)tid; +#elif defined(__FreeBSD__) +return (unsigned
long)pthread_getthreadid_np(); +#elif defined(__linux__) +
return (unsigned long)syscall(SYS_gettid); +#else +return
(unsigned long)pthread_self(); +#endif
Can we guarantee that pthread_self() will be available "by default"
since it's predicate-less, here? I wasn't able to quickly find a
reference for how to check for pthreads. Maybe #ifdef(_PTHREAD_H)?
That's a very valid point I forgot. I will investigate and test. Thank
you for raising! Surprisingly, I did not get a warning about a missing
prototype by HP aC.
M
[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=56210
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Position on failing tests with vendor-modified OpenSSL packages
Am 2020-04-24 um 18:30 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark and Michael, On 4/24/20 07:24, Michael Osipov wrote: Am 2020-04-24 um 08:57 schrieb Mark Thomas: On 24/04/2020 00:45, Michael Osipov wrote: Folks, I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are modified which make several tests fail. See an excerpt here [1]. To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all tests pass, so other must have modified OpenSSL. What is our position in terms of support/testing for modified OpenSSL packages from OS vendors? Should we add a big fat warning somewhere? Add this to tcnative README that we test/recommend upstream only? The good news is that the tests that are failing are the ones I would expect to fail. When we added the code that lets us use OpenSSL syntax to define ciphers for JSSE (and JSSE syntax to define ciphers for OpenSSL) we added a these tests to ensure that we correctly tracked things like "ALL", "DEFAULT" as well as "ECDHE" etc. These are a moving target as support for new ciphers is added and ciphers viewed as less secure are removed. Our unit tests aim to work with the current version of all publicly supported OpenSSL branches. Currently, master (3.0.x) and 1.1.1. I expect the vendor supported 1.0.2 packages are close to current 1.1.1 but I wouldn't be surprised to see some minor differences. I think we have several options: - document the expectation more clearly so folks can more easily assess these failures - support using the vendor supported versions with the unit tests - provide a configuration option to skip these tests - detect vendor supplied OpenSSL and automatically skip the tests We need to do at least the documentation. As for detectection and support: I consider this to be hardly solvable because there is no identifier in "openssl version -a" which says I have been modified by X. See: $ openssl version -a OpenSSL 1.0.2r 26 Feb 2019 built on: reproducible build, date unspecified platform: hpux-ia64-cc options: bn(64,64) rc4(idx,int) des(idx,risc1,16,long) blowfish(idx) compiler: cc -I. -I.. -I../include -I/ssh_ssl_build/ssl-build/OpenSSL_1_0_FIPS_205/build/zlib +Z -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD32 +O2 +Olit=all -z -DB_ENDIAN -D_REENTRANT -DOPENSSL_BN_ASM_MONT -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/opt/openssl" and $ openssl version -a OpenSSL 1.0.2k-fips 26 Jan 2017 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/etc/pki/tls" engines: rdrand dynamic The only option I see is to check for OS name/LSB release, call with depdency graph with ldd and check for libssl/libcrypto in default locations, but this is really really ugly. Compared to OpenSSL 1.1.1 from FreeBSD base and OpenSSL 1.0.2 compiled myself: $ openssl version -a OpenSSL 1.1.1e-freebsd 17 Mar 2020 built on: reproducible build, date unspecified platform: FreeBSD-amd64 options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) compiler: clang OPENSSLDIR: "/etc/ssl" ENGINESDIR: "/usr/lib/engines" Seeding source: os-specific Granted, this one says in the version string it is from FreeBSD. $ /tmp/openssl-1.0.2/bin/openssl version -a OpenSSL 1.0.2v-dev xx XXX built on: reproducible build, date unspecified platform: BSD-x86_64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/tmp/openssl-1.0.2/ssl" There are probably a few options I've missed. I will add at this point that debugging a failure and figuring out the right fix hasn't always easy. I'm currently wondering
Re: Building libtcnative with MinGW32
Am 2020-04-24 um 19:52 schrieb Mark Thomas: On 24/04/2020 18:43, Michael Osipov wrote: Folks, has anyone ever built libtcnative with MinGW32? I have build (lib)curl a fair amount of times with ease with MinGW. Download all the SDK along with minimal VS is overkill for such a small lib. How do you build on Windows? https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows Is anyone interested in this? Should we also consider building with CMake? The build process needs to build a single binary (OK and second one with OCSP enabled unless we enabled that be default) that: - works on all currently supported Microsoft Windows operating systems - works on a clean install of the base operating system with zero additional libraries, run-times, etc. The hoops we currently jump through in the build process are primarily to ensure this last point so the binary isn't dependent on one of the .net run-times or similar. If there is a simpler way to achieve the same result, that would be a win. Thanks, I will see whether we can provide a CMake-based build in the longterm also since this is way easier on Windows than fiddling with other cruft. libserf prodivers now a CMake-based builds and they too require libapr and libssl/crypto. I need to see whether one can join forces. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Building libtcnative with MinGW32
Folks, has anyone ever built libtcnative with MinGW32? I have build (lib)curl a fair amount of times with ease with MinGW. Download all the SDK along with minimal VS is overkill for such a small lib. How do you build on Windows? Is anyone interested in this? Should we also consider building with CMake? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Update Java source to latest 10.0.x
Am 2020-04-24 um 17:00 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat-native.git
The following commit(s) were added to refs/heads/master by this push:
new 14aebf3 Update Java source to latest 10.0.x
14aebf3 is described below
commit 14aebf346532ebf02306136edb31675624478556
Author: Mark Thomas
AuthorDate: Fri Apr 24 16:00:44 2020 +0100
Update Java source to latest 10.0.x
---
java/org/apache/tomcat/jni/Library.java| 2 +-
java/org/apache/tomcat/jni/OS.java | 7 ---
java/org/apache/tomcat/jni/SSL.java| 6 +++---
java/org/apache/tomcat/jni/SSLConf.java| 2 +-
java/org/apache/tomcat/jni/SSLContext.java | 6 +++---
java/org/apache/tomcat/jni/SSLSocket.java | 6 +++---
6 files changed, 11 insertions(+), 18 deletions(-)
diff --git a/java/org/apache/tomcat/jni/Library.java
b/java/org/apache/tomcat/jni/Library.java
index 9034e23..45956e1 100644
--- a/java/org/apache/tomcat/jni/Library.java
+++ b/java/org/apache/tomcat/jni/Library.java
@@ -249,7 +249,7 @@ public final class Library {
aprVersionString() + ")");
}
if (!APR_HAS_THREADS) {
-throw new UnsatisfiedLinkError("Missing threading support from
APR");
+throw new UnsatisfiedLinkError("Missing APR_HAS_THREADS");
That's not right for two reasons:
1. This test will go away soon. After 1.2.24 I will scope threading
support for OpenSSL < 1.1.0 only.
2. The flag itself isn't missing, it is simply not 1 (but 0). That's a
difference. Therefore, the error message is misleading. The previous
message has been taken intentionally from APR's "configure --help" output.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Position on failing tests with vendor-modified OpenSSL packages
Am 2020-04-24 um 08:57 schrieb Mark Thomas: On 24/04/2020 00:45, Michael Osipov wrote: Folks, I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are modified which make several tests fail. See an excerpt here [1]. To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all tests pass, so other must have modified OpenSSL. What is our position in terms of support/testing for modified OpenSSL packages from OS vendors? Should we add a big fat warning somewhere? Add this to tcnative README that we test/recommend upstream only? The good news is that the tests that are failing are the ones I would expect to fail. When we added the code that lets us use OpenSSL syntax to define ciphers for JSSE (and JSSE syntax to define ciphers for OpenSSL) we added a these tests to ensure that we correctly tracked things like "ALL", "DEFAULT" as well as "ECDHE" etc. These are a moving target as support for new ciphers is added and ciphers viewed as less secure are removed. Our unit tests aim to work with the current version of all publicly supported OpenSSL branches. Currently, master (3.0.x) and 1.1.1. I expect the vendor supported 1.0.2 packages are close to current 1.1.1 but I wouldn't be surprised to see some minor differences. I think we have several options: - document the expectation more clearly so folks can more easily assess these failures - support using the vendor supported versions with the unit tests - provide a configuration option to skip these tests - detect vendor supplied OpenSSL and automatically skip the tests We need to do at least the documentation. As for detectection and support: I consider this to be hardly solvable because there is no identifier in "openssl version -a" which says I have been modified by X. See: $ openssl version -a OpenSSL 1.0.2r 26 Feb 2019 built on: reproducible build, date unspecified platform: hpux-ia64-cc options: bn(64,64) rc4(idx,int) des(idx,risc1,16,long) blowfish(idx) compiler: cc -I. -I.. -I../include -I/ssh_ssl_build/ssl-build/OpenSSL_1_0_FIPS_205/build/zlib +Z -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD32 +O2 +Olit=all -z -DB_ENDIAN -D_REENTRANT -DOPENSSL_BN_ASM_MONT -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/opt/openssl" and $ openssl version -a OpenSSL 1.0.2k-fips 26 Jan 2017 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/etc/pki/tls" engines: rdrand dynamic The only option I see is to check for OS name/LSB release, call with depdency graph with ldd and check for libssl/libcrypto in default locations, but this is really really ugly. Compared to OpenSSL 1.1.1 from FreeBSD base and OpenSSL 1.0.2 compiled myself: $ openssl version -a OpenSSL 1.1.1e-freebsd 17 Mar 2020 built on: reproducible build, date unspecified platform: FreeBSD-amd64 options: bn(64,64) rc4(16x,int) des(int) idea(int) blowfish(ptr) compiler: clang OPENSSLDIR: "/etc/ssl" ENGINESDIR: "/usr/lib/engines" Seeding source: os-specific Granted, this one says in the version string it is from FreeBSD. $ /tmp/openssl-1.0.2/bin/openssl version -a OpenSSL 1.0.2v-dev xx XXX built on: reproducible build, date unspecified platform: BSD-x86_64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/tmp/openssl-1.0.2/ssl" There are probably a few options I've missed. I will add at this point that debugging a failure and figuring out the right fix hasn't always easy. I'm currently wondering if some sort of combination of the above might work. Detect vendor variations, handle them where we can recognise them and skip them
Position on failing tests with vendor-modified OpenSSL packages
Folks, I run test from Tomcat master and libtcnative master on FreeBSD, RHEL 7 and HP-UX 11.31 on a regular basis and noticed that the OpenSSL 1.0.2 packages provided by Red Hat and HPE are modified which make several tests fail. See an excerpt here [1]. To verify this I have compiled OpenSSL from OpenSSL_1_0_2-stable on FreeBSD w/o any modification and all tests pass, so other must have modified OpenSSL. What is our position in terms of support/testing for modified OpenSSL packages from OS vendors? Should we add a big fat warning somewhere? Add this to tcnative README that we test/recommend upstream only? [1] http://home.apache.org/~michaelo/issues/openssl-tests/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] branch master updated: Tweak wording. Fix typo.
Am 2020-04-23 um 18:48 schrieb ma...@apache.org: This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-native.git The following commit(s) were added to refs/heads/master by this push: new 3cc27fa Tweak wording. Fix typo. 3cc27fa is described below commit 3cc27faf7da0990c143cad8a68bda884d8c524db Author: Mark Thomas AuthorDate: Thu Apr 23 17:48:12 2020 +0100 Tweak wording. Fix typo. --- native/srclib/VERSIONS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/native/srclib/VERSIONS b/native/srclib/VERSIONS index 52ef8fa..f6b09de 100644 --- a/native/srclib/VERSIONS +++ b/native/srclib/VERSIONS @@ -3,5 +3,5 @@ The following version of the libraries are recommended: - APR 1.7.0 or later, http://apr.apache.org - OpenSSL 1.1.1g or later, http://www.openssl.org -Older versions may also work but are not as throughly tested by the Tomcat +Older versions should also work but are not as thoroughly tested by the Tomcat I am happy with that. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] 02/03: Update version recommendations
Am 2020-04-23 um 17:43 schrieb ma...@apache.org: This is an automated email from the ASF dual-hosted git repository. markt pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-native.git commit 04497fe553ac4a5497eeb7c011275c8e14eb6fec Author: Mark Thomas AuthorDate: Thu Apr 23 16:25:10 2020 +0100 Update version recommendations --- native/srclib/VERSIONS | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/native/srclib/VERSIONS b/native/srclib/VERSIONS index a5feb4c..52ef8fa 100644 --- a/native/srclib/VERSIONS +++ b/native/srclib/VERSIONS @@ -1,4 +1,7 @@ -Use the following version of the libraries +The following version of the libraries are recommended: -- APR 1.6.5 or later, http://apr.apache.org -- OpenSSL 1.0.2r or later, http://www.openssl.org +- APR 1.7.0 or later, http://apr.apache.org +- OpenSSL 1.1.1g or later, http://www.openssl.org + +Older versions may also work but are not as throughly tested by the Tomcat +Native team This looks wrong to me in a patch version. This should have happened in December with a proper announcement and with a 1.3 release of libtcnative. Also consider that there are no effective changes in 1.7.0 [1] for us which require/recommend using 1.7.x at all. Please revert, release 1.2.24, announce recommendation for 1.3, bump master to 1.3. Michael [1] https://downloads.apache.org/apr/CHANGES-APR-1.7 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Time for Tomcat Native 1.2.24?
Am 2020-04-22 um 12:34 schrieb Mark Thomas: Hi all, You have probably seen this: OpenSSL - CVE-2020-1967 https://openssl.markmail.org/thread/nuamcatocap7rwrw I have reviewed the Tomcat Native code and confirmed that we do not call SSL_check_chain() at any point. I also looked at the OpenSSL code as I was concerned that we might hit the same problem via an internal code path. It appears I wasn't the only one with that concern and the OpenSSL team confirmed that the issue only occurs when calling SSL_check_chain(): https://openssl.markmail.org/thread/okfaim5oqhh2egj6 Therefore, it is not necessary to roll a new Tomcat Native release to pick up an updated OpenSSL version for the Windows binaries. That said, there are a few Tomcat Native fixes since 1.2.23 and it has been 9 months since the last release. We should have enough time to get a 1.2.24 release out if we want to. Thoughts? This sounds good to me. I'd like to add one more thing: remove dep on apr_thread_id in ssl_thread_id() because our impl is so elaborate that using APR here adds no benefit. With this change we can completely isolate the requirement of APR threading support to pre OpenSSL 1.1.0 usage. But this will be for 1.2.25. I will work on this little thing this week. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 7.0.x updated: Remove redundant sole path/URI from error page message on SC_NOT_FOUND
Am 2020-04-20 um 15:11 schrieb Konstantin Kolinko: пн, 20 апр. 2020 г. в 11:05, Mark Thomas : On 18/04/2020 20:59, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/7.0.x by this push: new 08879ae Remove redundant sole path/URI from error page message on SC_NOT_FOUND 08879ae is described below commit 08879aeb5e30933bc0a6aaea6c1fa8a9ef4b8a58 Author: Michael Osipov AuthorDate: Sat Apr 18 20:58:40 2020 +0200 Remove redundant sole path/URI from error page message on SC_NOT_FOUND When a component issues a SC_NOT_FOUND don't respond with the path/URI only in the error message because it does not offer any more detail about the error, plus the client knows the path/URI already. Not necessarily. The client has no visibility of forwards or includes. In a more complex application it might not be obvious that a forward / include has occurred. Including the path for the resource that could not be found makes debugging significantly easier. I think this change should be reverted. I am -1 on this change. I agree that it should be reverted. I have seen this message from DefaultServlet many times and it is rather useful. If a programmer wants to hide the error path, the widely used practice is to configure a custom error page for the error code 404. I cannot comment on other servlets (WebdavServlet, SSIServlet, JSPServlet) touched by this commit. this will also apply to JSP servlet when you ask the request dispatcher to forward to a JSP page. I will work on decent messages for DefaultServlet and JSPServlet tomorrow. The WebDavServlet makes no real sense because the responses are for automated clients. They will happily ignore the HTML error page. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 7.0.x updated: Remove redundant sole path/URI from error page message on SC_NOT_FOUND
Am 2020-04-20 um 11:11 schrieb Rémy Maucherat: On Mon, Apr 20, 2020 at 10:58 AM Michael Osipov wrote: Am 2020-04-20 um 10:05 schrieb Mark Thomas: On 18/04/2020 20:59, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/7.0.x by this push: new 08879ae Remove redundant sole path/URI from error page message on SC_NOT_FOUND 08879ae is described below commit 08879aeb5e30933bc0a6aaea6c1fa8a9ef4b8a58 Author: Michael Osipov AuthorDate: Sat Apr 18 20:58:40 2020 +0200 Remove redundant sole path/URI from error page message on SC_NOT_FOUND When a component issues a SC_NOT_FOUND don't respond with the path/URI only in the error message because it does not offer any more detail about the error, plus the client knows the path/URI already. Not necessarily. The client has no visibility of forwards or includes. In a more complex application it might not be obvious that a forward / include has occurred. Including the path for the resource that could not be found makes debugging significantly easier. For the dev likely, for the user still irrelevant. What about logging at debug level for the dev to still be able to find issues (like in SSIServlet)? At the end, only the dev cares about more context. WDYT? I would also prefer keeping them. This way users can report a more useful error. What about a more descriptive message rather than the blunt path/URL? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection close for POST after successful expectation and status 302
Am 2020-04-20 um 11:32 schrieb Mark Thomas: On 20/04/2020 09:52, Michael Osipov wrote: Am 2020-04-19 um 17:32 schrieb Rainer Jung: Hi Michael, Am 19.04.2020 um 17:11 schrieb Michael Osipov: Am 2020-04-19 um 14:40 schrieb Rainer Jung: I observed this when using Apache mod_proxy_http and mod_proxy_balancer with ping=5000, which wil add the expectation to any POST request. I wanted to tune Apache/Tomcat communication to use connections very long in order to reduce TLS handshakes during the servers. It turned out, that because the application always does redirect-after-POST and due to the above described TC behavior, the effective reuse for the connections was very small. Regardless of the problem itself. Why does the module modify the request? Isn't the ping supposed to work via HEAD with expect: 100-continue at most? Not that I am aware of. AFAIK the expectation is only allowed for requests with bodies. That's nonsense from my side. Mental disconception. That's what I see when applying patches to mod_proxy_http recently. That would be a surpsise to me, especially after checking trunk and 2.4 now again. Any code citation? Note I am talking about mod_proxy_http ping, not the AJP one and not the H2 one. I'd need to go more deeply into the code, but from my memory I discussed aspects from this in BZ 63626 with Rüdiger and Yann. I may be wrong, of course! Some clients don't even handle the expect header, like browsers. Not a question of clients here. They do not have to support it for the reverse proxy ping feature. It only changes communication between proxy and back end, the client will not see a difference. But that all is not really related to my original question. Why is TC closing the connection after a successful expectation handling and fully reading the request body when the application returns a non-2xx response (eg. a 3xx)? Right, the question is what qualifies to close a connection if this has not been done explicitly like from application code or in #statusDropsConnection(). The comment in that block: // to ensure that the connection is closed. Some clients may // still send the body, some may send the next request. // No way to differentiate, so close the connection to // force the client to send the next request. is a safety net from my understanding for misbehaving clients. That understanding is not correct. The check is there to avoid security issues. The spec allows the client to send the request body at any time and the server has no way of differentiating the client sending the request body vs the client sending the next request. If the server can't be sure it has received the entire request body (and hence the next data received must be the next request) it MUST close the connection for security. But you are right, there is no reason why it should be closed with a 3xx at least. Yes there is. See above. Thank you for the explanation. So you consider 3xx not to be complete as 2xx to qualify the for connecton closure because the client is supposed to issue another request on that connection? If so, you are absolutely right. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 7.0.x updated: Remove redundant sole path/URI from error page message on SC_NOT_FOUND
Am 2020-04-20 um 10:05 schrieb Mark Thomas: On 18/04/2020 20:59, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a commit to branch 7.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/7.0.x by this push: new 08879ae Remove redundant sole path/URI from error page message on SC_NOT_FOUND 08879ae is described below commit 08879aeb5e30933bc0a6aaea6c1fa8a9ef4b8a58 Author: Michael Osipov AuthorDate: Sat Apr 18 20:58:40 2020 +0200 Remove redundant sole path/URI from error page message on SC_NOT_FOUND When a component issues a SC_NOT_FOUND don't respond with the path/URI only in the error message because it does not offer any more detail about the error, plus the client knows the path/URI already. Not necessarily. The client has no visibility of forwards or includes. In a more complex application it might not be obvious that a forward / include has occurred. Including the path for the resource that could not be found makes debugging significantly easier. For the dev likely, for the user still irrelevant. What about logging at debug level for the dev to still be able to find issues (like in SSIServlet)? At the end, only the dev cares about more context. WDYT? M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Dropping reason phrase in WebDavServlet
Am 2020-04-20 um 10:25 schrieb Mark Thomas: On 18/04/2020 21:19, Michael Osipov wrote: Folks, the WebDAV servlet still sends a reason phrase on multistatus (207).I'd like to drop it in master and 9.0.x. It is inconsistent with the behavior with these versions. Any objections/opinions on dropping it? I agree it is inconsistent and I'm generally in favour of anything that improves consistentcy, simplifies, etc. RFC 4918 (WebDAV) references RFC 2616 (HTTP/1.1) where the language is slightly less strong (the client is "not required" to examine it) than RFC 7230 (the client SHOULD ignore it). However, even in RFC 2616 an empty reason phrase is valid. So I think the specs support this change. WebDAV clients, particularly the Microsoft implementations, can have very specific expectations about server behaviour that are not required by the RFC. I think it would be prudent to at least test this change to the WebDAV server implementation with the current Microsoft WebDAV client implementations before rolling it out. I can easily test Windows Explorer, CarrotDAV and maybe Dolphin with SPNEGO enabled at work. But I need to see wether it works with Microsoft's implementation at all. Will get back to this in a few days. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection close for POST after successful expectation and status 302
Am 2020-04-19 um 17:32 schrieb Rainer Jung: Hi Michael, Am 19.04.2020 um 17:11 schrieb Michael Osipov: Am 2020-04-19 um 14:40 schrieb Rainer Jung: I observed this when using Apache mod_proxy_http and mod_proxy_balancer with ping=5000, which wil add the expectation to any POST request. I wanted to tune Apache/Tomcat communication to use connections very long in order to reduce TLS handshakes during the servers. It turned out, that because the application always does redirect-after-POST and due to the above described TC behavior, the effective reuse for the connections was very small. Regardless of the problem itself. Why does the module modify the request? Isn't the ping supposed to work via HEAD with expect: 100-continue at most? Not that I am aware of. AFAIK the expectation is only allowed for requests with bodies. That's nonsense from my side. Mental disconception. That's what I see when applying patches to mod_proxy_http recently. That would be a surpsise to me, especially after checking trunk and 2.4 now again. Any code citation? Note I am talking about mod_proxy_http ping, not the AJP one and not the H2 one. I'd need to go more deeply into the code, but from my memory I discussed aspects from this in BZ 63626 with Rüdiger and Yann. I may be wrong, of course! Some clients don't even handle the expect header, like browsers. Not a question of clients here. They do not have to support it for the reverse proxy ping feature. It only changes communication between proxy and back end, the client will not see a difference. But that all is not really related to my original question. Why is TC closing the connection after a successful expectation handling and fully reading the request body when the application returns a non-2xx response (eg. a 3xx)? Right, the question is what qualifies to close a connection if this has not been done explicitly like from application code or in #statusDropsConnection(). The comment in that block: // to ensure that the connection is closed. Some clients may // still send the body, some may send the next request. // No way to differentiate, so close the connection to // force the client to send the next request. is a safety net from my understanding for misbehaving clients. But you are right, there is no reason why it should be closed with a 3xx at least. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Connection close for POST after successful expectation and status 302
Am 2020-04-19 um 14:40 schrieb Rainer Jung: I observed this when using Apache mod_proxy_http and mod_proxy_balancer with ping=5000, which wil add the expectation to any POST request. I wanted to tune Apache/Tomcat communication to use connections very long in order to reduce TLS handshakes during the servers. It turned out, that because the application always does redirect-after-POST and due to the above described TC behavior, the effective reuse for the connections was very small. Regardless of the problem itself. Why does the module modify the request? Isn't the ping supposed to work via HEAD with expect: 100-continue at most? That's what I see when applying patches to mod_proxy_http recently. Some clients don't even handle the expect header, like browsers. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Dropping reason phrase in WebDavServlet
Folks, the WebDAV servlet still sends a reason phrase on multistatus (207).I'd like to drop it in master and 9.0.x. It is inconsistent with the behavior with these versions. Any objections/opinions on dropping it? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Proposed Connector API and XML refactoring
Am 2020-04-17 um 16:58 schrieb Rémy Maucherat: On Fri, Apr 17, 2020 at 2:19 PM Michael Osipov wrote: Isn't that obvious a soon as I provide sslImplementationName/? With the new config SSLHostConfig, SSLEnabled seems to be derivable from that since it's mandatory. This wasn't practical before. However, I see code that also checks the flag in addSslHostConfig. So I am still not comfortable removing it right now. So since there seems to be continued skepticism about the new XML, the best seems to be to do nothing. I am not really skeptical about it, all I am saying is that redundant stuff should be dropped and the configuration should be straight forward. Your idea goes in the right way. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Proposed Connector API and XML refactoring
Am 2020-04-17 um 14:02 schrieb Rémy Maucherat: On Fri, Apr 17, 2020 at 11:51 AM Michael Osipov wrote: Am 2020-04-15 um 23:05 schrieb r...@apache.org: This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new 92923fe Proposed Connector API and XML refactoring 92923fe is described below commit 92923febadb5d7901747530272302dc3da6311c2 Author: remm AuthorDate: Wed Apr 15 23:04:47 2020 +0200 Proposed Connector API and XML refactoring See https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring To add some fuel to the fire: This looks like a start. I always liked the approach HTTPd took, addd a Listen : + VirtualHost :. Even in the new proposal you have redundancies: scheme, secure, SSLEnabled. Why can't the endpoint or rather a class using this endpoint There's actually no duplication with these attributes. SSLEnabled: actually use TLS on the connector Isn't that obvious a soon as I provide sslImplementationName/? secure: Tomcat considers the data received from the client has been kept secure end to end Is that so? How can I guarantee -- as a client -- that a middle box (forwarding proxy) enforces secure comminication? Docs say this: Set this attribute to true if you wish to have calls to request.isSecure() to return true for requests received by this Connector. scheme: the protocol scheme to be used on the URL (http or https basically) This is determined/implied by the protocol handler you use. Saying: and looks just wrong because with ALPN it won't be https, but h2. No TLS is used, you still can try h2c directly if you know upfront. From an admin point of view, this is messy and confusing. Always consider that admins aren't devs. Our admins keeps asking me things about Tomcat config options because they are beyond his understanding as an admin. My understanding is: * An endpoint impl is a pure socket which can run any protocol * A protocol is uses an endpoint * A Host declares to use a specific endpoint/protocol * Either proto or host declare TLS Which such decoupling one could even introduce AJPS. But a guess this is a lot of work to do. Indeed that's not what we do. I guess everyone involved with Catalina was skeptical and considered the current nested container structure was flexible enough. Having said that, I don't think it is flexible enough. It is flexible at places not strictly requiring it while in others limited. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Proposed Connector API and XML refactoring
Am 2020-04-15 um 23:05 schrieb r...@apache.org: This is an automated email from the ASF dual-hosted git repository. remm pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/tomcat.git The following commit(s) were added to refs/heads/master by this push: new 92923fe Proposed Connector API and XML refactoring 92923fe is described below commit 92923febadb5d7901747530272302dc3da6311c2 Author: remm AuthorDate: Wed Apr 15 23:04:47 2020 +0200 Proposed Connector API and XML refactoring See https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring To add some fuel to the fire: This looks like a start. I always liked the approach HTTPd took, addd a Listen : + VirtualHost :. Even in the new proposal you have redundancies: scheme, secure, SSLEnabled. Why can't the endpoint or rather a class using this endpoint decide what protocol it speaks when TLS config is nested? What I never understood with Tomcat why Host configs applies to *all* connectors. I cannot freely apply hosts to IP/port combos and selecting on a host level what type of protocol I want to have. My understanding is: * An endpoint impl is a pure socket which can run any protocol * A protocol is uses an endpoint * A Host declares to use a specific endpoint/protocol * Either proto or host declare TLS Which such decoupling one could even introduce AJPS. But a guess this is a lot of work to do. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remaining Tomcat 10 items
Am 2020-03-23 um 10:37 schrieb Rémy Maucherat: Hi, I'm looking at the TODO list, in addition to some extra items. In order ... You missed one point: Remove deprecated code marked for removal in Tomcat 10. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Remaining Tomcat 10 items
Am 2020-03-23 um 15:42 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rémy, On 3/23/20 05:37, Rémy Maucherat wrote: I'm looking at the TODO list, in addition to some extra items. In order ... - Remove APR connector. Is there still general approval for that, and is that still the plan for Tomcat 10.0 ? See the thread "[PROPOSAL] Tomcat 10: Drop AJP Connector" from 2019-10-07 and later. All replies were in favor of dropping AJP support, though there were not a large number of those replies. (michael-o had a concern about some performance problem in the HTTP connector(s) but it seems that was a regression that was corrected immediately after it was reported.) It was a misconfiguration of the tests on master. With Mark's test code I was able to find the minimal required buffer size for three operating systems. I will run master tests on several OSes and OpenJDK versions again and compare numbers. If they are significantly different, I will report them. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Request line parsing
Am 2020-03-23 um 14:01 schrieb Mark Thomas: Hi, I am currently looking at the request line parsing. I'll try and set out each issue in turn. End of line parsing === Prior to the recent changes, Tomcat allowed CRLF or LF to mark the end of a line. The unwanted side effect was that CR could appear in the header value. This caused problems and was tightened up to only allow CRLF as a line terminator. Currently Tomcat requires CRLF everywhere apart from the end of the request line for a HTTP 0.9 request where it also allows LF. This requirement to accept just LF as a line terminator first emerged in the W3C spec [1]. RFC 1945 [2] and RFC 2616 [3] retained this as a recommendation for all line terminators, RFC 7230 [4] no longer includes this recommendation. RFC 7230 also removes the expectation that a server that supports HTTP/1.1 will support HTTP 0.9. Arguably the current spec for HTTP/0.9 is [3]. The Servlet spec references RFC 7230 and RFC 1945 so arguably HTTP/0.9 support is expected. SP vs whitespace Tomcat currently accepts any combination of SP and HTAB where RFC 7230 calls for a single SP. This stems from a recommendation in RFC 2616 which is no longer present in RFC 7230. I think we have three options. 1. No changes. CRLF is required everywhere apart from HTTP/0.9 where LF is also accepted. Any combination of SP/HTAB is accepted where SP is required. 2. Tighten up as per RFC 7230 a) Require CRLF for all line endings b) Require SP where specified c) Drop HTTP/0.9 support 3. Relax the recent changes to allow CRLF or LF as a line terminator everywhere without allowing CR to appear in a request header. I think we should follow 1) for Tomcat 7, 8 & 9. I'm leaning towards 1 for 10.0.x as well with a view to discussing 2 in the Servlet project. i.e. explicitly dropping HTTP 0.9 support and the "Tolerant applications" requirements of RFC 1945 for Jakarta EE 10 (Tomcat 10.1.x). Makes sense for <= 9 and the evaluation for 10 M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Proposed changes to UDecoder.ALLOW_ENCODED_SLASH
Am 2020-03-13 um 15:35 schrieb Mark Thomas:
Hi all,
I am writing this up as this is a change I'd like to make in Tomcat 10
that I think is important to get right. It may also get back-ported.
This first arose in this mod_jk bug:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459
Ignoring the mod_jk aspects for now (they will come later) the bug
report raises the important question of how to handle the case where the
ID for a resource in a RESTful API includes a "/".
At the moment, Tomcat does not handle this correctly. If
ALLOW_ENCODED_SLASH is false, the request is rejected. If it is true,
the wrong resource identifier will be used. This is an edge case, but
one I'd like to fix.
My research led me back to RFC 3986. Quoting from section 2.2:
The purpose of reserved characters is to provide a set of delimiting
characters that are distinguishable from other data within a URI.
URIs that differ in the replacement of a reserved character with its
corresponding percent-encoded octet are not equivalent. Percent-
encoding a reserved character, or decoding a percent-encoded octet
that corresponds to a reserved character, will change how the URI is
interpreted by most applications. Thus, characters in the reserved
set are protected from normalization and are therefore safe to be
used by scheme-specific and producer-specific algorithms for
delimiting data subcomponents within a URI.
My reading of this is that there are some %nn sequences that we should
*never* decode. The values we pass to applications for ServletPath,
PathInfo etc. should still include these %nn sequences and the
application should decode them.
My next thought was "Which %nn sequences should be leave alone?". That
got me thinking about URIEncoding values and how to differentiate
between a %nn sequence we wanted to leave alone and the same sequence
appearing where a code point is represented by multiple bytes.
Fortunately, RFC7230 saves us from that complication as it requires all
encodings to be supersets of US-ASCII. Or to put is another way, the
only time %nn appears where nn is in the range 00 to 7F that %nn
sequence will *always* be representing the equivalent US-ASCII code point.
So, that simplifies things a little as we go back to considering which
%nn sequences we have to leave alone.
The starting point is "reserved" characters. From RFC 3986:
reserved= gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
We are talking about URIs in Tomcat which, at the point we %nn decode,
is just the path. The path parameters and query string have been removed.
From RFC 7230:
absolute-path = 1*( "/" segment )
and from RFC 3986:
segment = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
So the question is, which reserved characters cannot be safely decoded
from their %nn form.
We know all subdelims because:
- they are valid characters in a segment and with the query string and
path parameters removed, none of those characters have special meaning
That leaves gen-delims
Of those ":" and "@" are explicitly allowed in a segment. So that leaves:
"/" "?" "#" "[" "]"
"?" is the query delimiter but the query string has been removed so it
is safe to %nn decode to "?".
"#" is the fragment delimiter. The fragment will never reach the server
so it is safe to %nn decode to "#".
"[" and "]" are delimiters in the host but not the path so they are safe.
That just leaves "/".
My proposal is, therefore, actually very simple:
1. Remove the UDecoder.ALLOW_ENCODED_SLASH option.
2. Replace it with a per Connector setting that has three options:
a) deny (equivalent to ALLOW_ENCODED_SLASH="false")
b) decode (equivalent to ALLOW_ENCODED_SLASH="true")
c) allow (leaves as is)
I am CC'ing our expert olegk@ on this topic because at HttpComponents we
had numerous JIRA issues regarding the handling and RFC 3986
interpretation. It is, sadly, a constant source of trouble.
Oleg, can you share your view on Mark's proposal?
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-native] Installation structure
Chris, Am 2020-03-09 um 22:22 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 3/9/20 10:20, Michael Osipov wrote: Folks, I have been recently reviewing some downstream changes in tomcat-native. Can someone explain me why we install headers files along with .pc file? . ├── bin ├── include │ ├── ssl_private.h │ ├── tcn_api.h │ ├── tcn_version.h │ └── tcn.h └── lib ├── libtcnative-1.a ├── libtcnative-1.la ├── libtcnative-1.so -> libtcnative-1.so.0.2.23 ├── libtcnative-1.so.0 -> libtcnative-1.so.0.2.23 ├── libtcnative-1.so.0.2.23 └── pkgconfig └── tcnative-1.pc Why is bin dir created although we don't install anything into it?! ssl_private.h shouldn't definitively be there. What about the rest? Does it really make sense to install them at all? Can/Are there (be) any C users who compile and link against libtcnative? It seems strange, but yes, we do have downstream libtcnative users. I have no idea why they are using our wrappers. Occasionally, we get a bug report about some basically-never-used function in libtcnative, like the File API [1]. you are confusing downstream Java users with C users. If you look closely at those headers, they all define internal structs. There isn't a single prototype for public functions, yet no JNIEXPORT. All export is done in C code. None of these headers are intended to be used in an external C program and being linked with -ltcnative-1. In fact, they even require either OpenSSL and/or APR header files which breaks the abstraction from both. Maybe someone else with more C knowledge can look into, Rainer? I'd open a ticket to drastically reduce the install target to the libraries only. Java users aren't affected at all because they load the dynamic library and access all symbols marked with JNIEXPORT. We should probably formally deprecate like 50% of libtcnative with an eye toward throwing out all that code. Even better, we should drop the APR connectors which would discard even more code. Even better than THAT, we should look at how to direct-call OpenSSL/LibeSSL without having to use our own wrappers and completely throw-away libtcnative entirely. I think this is "Project Panama" and is something that evidently is actually arriving. Java 12 had some of the initial work shipped with it, and Java 13 has continued that effort. The only viable alternative I see at the moment is https://github.com/wildfly-security/wildfly-openssl. Panama is too early and consider that Tomcat 10 is still Java 8, so unless Tomcat 11 isn't Java 17 this won't happen anytime soon. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tomcat-native] Installation structure
Folks, I have been recently reviewing some downstream changes in tomcat-native. Can someone explain me why we install headers files along with .pc file? . ├── bin ├── include │ ├── ssl_private.h │ ├── tcn_api.h │ ├── tcn_version.h │ └── tcn.h └── lib ├── libtcnative-1.a ├── libtcnative-1.la ├── libtcnative-1.so -> libtcnative-1.so.0.2.23 ├── libtcnative-1.so.0 -> libtcnative-1.so.0.2.23 ├── libtcnative-1.so.0.2.23 └── pkgconfig └── tcnative-1.pc Why is bin dir created although we don't install anything into it?! ssl_private.h shouldn't definitively be there. What about the rest? Does it really make sense to install them at all? Can/Are there (be) any C users who compile and link against libtcnative? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Issue with tomcat-native.git
Folks, is it just me or is something wrong with tomcat-native.git on GitBox? PS C:\Users\osipovmi> git --version git version 2.25.0.windows.1 PS C:\Users\osipovmi> git clone https://gitbox.apache.org/repos/asf/tomcat-native.git Cloning into 'tomcat-native'... remote: Counting objects: 65115, done. remote: Compressing objects: 100% (13385/13385), done. remote: Total 65115 (delta 45424), reused 64843 (delta 45265) Receiving objects: 100% (65115/65115), 12.90 MiB | 52.00 KiB/s, done. Resolving deltas: 100% (45424/45424), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. > $ git --version > git version 2.25.0 $ LC_ALL=C.UTF-8 git clone https://gitbox.apache.org/repos/asf/tomcat-native.git Cloning into 'tomcat-native'... remote: Counting objects: 65115, done. remote: Compressing objects: 100% (13385/13385), done. remote: Total 65115 (delta 45425), reused 64843 (delta 45265) Receiving objects: 100% (65115/65115), 12.90 MiB | 209.00 KiB/s, done. Resolving deltas: 100% (45425/45425), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. If this is persistent and can be reproduced elsewhere I'd open an INFRA ticket. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: The future of Gump
Am 2020-03-07 um 21:11 schrieb Mark Thomas: Hi all, The Gump project has reached the point where Tomcat is the only ASF project using it. The Gump community is currently discussing options for the future. One of those options is status quo which would have no impact on us. Another option is the attic. If that were to happen, the vmgump service would potentially go away. vmgump has been very useful to the Tomcat community. It seems to have a knack of finding concurrency bugs. It also, recently, found a regression in OpenSSL master enabling us to get that fixed. If gump heads to the attic is the Tomcat community prepared to: a) take over the management of the vmgump service? b) take over the maintenance of the gump code (occasionally code changes are required like when Maven Central started to require https) In reality I do most of a) and b) already and I would continue doing so if they moved to Tomcat. Note that all of this is hypothetical at this point. The Gump PMC has not made a decision yet. Thoughts? Counter question: Why not go to https://builds.apache.org/? How much of your time does a) and b) consume? What if even more burden is put on you, is that acceptable for you? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [Tomcat 10] Dropping deprecations/renaming typos in public API
Am 2020-03-07 um 11:28 schrieb Mark Thomas: On 07/03/2020 09:13, Michael Osipov wrote: Folks, just wanted to make sure to avoid reverts. I want to start to drop all deprecated stuff I have marked/participated in the last couple years. What if a public API contains a typo? Are we fine to rename that? It depends on how public the public API is and how long it has been present. We are sometimes a little more relaxed about what is technically a public API but is deep inside the Tomcat internals and has only recently been added. We try and keep compatibility between major versions if we can. Usually, API changes are fine in the current development branch up to the point where it is declared stable. Then we need to be more careful. At the moment, removal in 10 is probably OK provided the code is deprecated in 9.0.x with a note it will be removed in 10.0.x. Fixing typos would normally be done by adding the correct method and deprecating the old one. There aren't any hard and fast rules. Some of this is subjective rather than objective. Reverting stuff isn't a big deal but you can always provide a PR for review if you want to get feedback first. Oh, and we can't touch the spec APIs. We have to follow what the Jakarta projects do. That's sounds pretty reasonable. My intention was to delete marked for removal in Tomcat 10. Never touch external API related stuff, Servlet, JSP, etc. If renames are in doubt I will create PRs. Thank you for the confirmation! Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat 10] Dropping deprecations/renaming typos in public API
Folks, just wanted to make sure to avoid reverts. I want to start to drop all deprecated stuff I have marked/participated in the last couple years. What if a public API contains a typo? Are we fine to rename that? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.52
Am 2020-03-06 um 12:51 schrieb Mark Thomas: The proposed Apache Tomcat 8.5.52 release is now available for voting. The major changes compared to the 8.5.51 release are: - Add new attribute persistAuthentication to both StandardManager and PersistentManager to support authentication persistence. Patch provided by Carsten Klein - A zero length AJP secret will now behave as if it has not been specified. - Add the TLS request attributes used by IIS to the attributes that an AJP Connector will always accept. Along with lots of other bug fixes and improvements. For full details, see the changelog: https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.52/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1252/ The tag is: https://github.com/apache/tomcat/tree/8.5.52 c83fd06b3cd0c96ffd7dc660107a1283b714483b Stable for me with * apr 1.7.0 * tcnative 1.2.23 * openssl 1.1.1d-freebsd and Java version: 1.8.0_242, vendor: Oracle Corporation, runtime: /usr/local/openjdk8/jre Default locale: de_DE, platform encoding: UTF-8 OS name: "freebsd", version: "12.1-stable", arch: "amd64", family: "unix" Suprisingly, some tests fail repeatedly with 1.2.21. +1 from me. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
Am 2020-02-24 um 21:35 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael, On 2/24/20 14:15, Michael Osipov wrote: Am 2020-02-24 um 17:33 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm trying to cherry-pick a commit. The commit went through github, merged a PR from a contributor into master. I'm trying to cherry-pick it back into the 9.0.x branch: $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no -m option was given. fatal: cherry-pick failed ?? My local copy is all up-to-date, no weird local changes or anything like that. What is a "merge", here? Supplying "-m" doesn't like the commit id. $ git log --graph * commit 900ed3ef96080ec378fea452dcd748bf3bfa0ec0 (HEAD -> master, origin/master, origin/HEAD) | Author: Christopher Schultz | Date: 2020-02-24 17:26:31 +0100 | | Add changelog entry. | * commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f |\ Merge: 03b2af7473 bf2447b4bd | | Author: Christopher Schultz | | Date: 2020-02-24 17:21:31 +0100 | | | | Merge pull request #240 from ThStock/master | | | | Added extension point for custom delta requests | | | * commit bf2447b4bd9edda25e00c7aaab9fcce455c43f2f | | Author: Thomas Stock | | Date: 2020-02-13 12:55:32 +0100 | | | | Added extension point for custom delta requests | | You can't cherry-pick merge commits. WTF is a merge-commit? A merge commit reconciles two or more tree where history has dirverged from each other. Try to avoid merge commits. I clicked "Merge PR" in GitHub. I don't believe I had any choices in the matter. I already assumed so. GitHub is stupid and creates this useless commit. On the right-hand side of that button is a menu button which does rebase and merge. See here: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/merging-a-pull-request In most cases all they do is to add clutter with zero benefit [1]. Single-click to accept a PR is great. I see that is CAN cause (me) problems, but it shouldn't be this hard. It is hard, if you don't know what it is doing it exactly. Rebase the branch you want to merge on top of the targer branch, switch and then merge. I don't control the source's github fork, so that's a no-go. That's not a no go. You mostly have this: Add more commits by pushing to the session-manager-persist-authentication branch on cklein05/tomcat. If you don't, request the PR creator to do the rebase, alternatively use your clone from Gitbox, create a branch and merge the foreign branch. If everything is fine, merge into master. With that, you have full control. This is how we merge PR in Maven. M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: git-fu is weak
Am 2020-02-24 um 17:33 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm trying to cherry-pick a commit. The commit went through github, merged a PR from a contributor into master. I'm trying to cherry-pick it back into the 9.0.x branch: $ git cherry-pick f124a9c7230227d3eaff9d2dc1c52f82ce10e03f error: commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f is a merge but no -m option was given. fatal: cherry-pick failed ?? My local copy is all up-to-date, no weird local changes or anything like that. What is a "merge", here? Supplying "-m" doesn't like the commit id. $ git log --graph * commit 900ed3ef96080ec378fea452dcd748bf3bfa0ec0 (HEAD -> master, origin/master, origin/HEAD) | Author: Christopher Schultz | Date: 2020-02-24 17:26:31 +0100 | | Add changelog entry. | * commit f124a9c7230227d3eaff9d2dc1c52f82ce10e03f |\ Merge: 03b2af7473 bf2447b4bd | | Author: Christopher Schultz | | Date: 2020-02-24 17:21:31 +0100 | | | | Merge pull request #240 from ThStock/master | | | | Added extension point for custom delta requests | | | * commit bf2447b4bd9edda25e00c7aaab9fcce455c43f2f | | Author: Thomas Stock | | Date: 2020-02-13 12:55:32 +0100 | | | | Added extension point for custom delta requests | | You can't cherry-pick merge commits. Try to avoid merge commits. In most cases all they do is to add clutter with zero benefit [1]. Rebase the branch you want to merge on top of the targer branch, switch and then merge. This is trivial via shell. [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html?source=techstories.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Tomcat 7.0.x EOL as 31 March 2021
Am 2020-02-21 um 10:52 schrieb Mark Thomas: All, This has been mentioned in various threads and I don't recall any objections. I think it is time for a vote so we can formally announce this. Announce the EOL date for 7.0.x as 31 March 2021 +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 7.0.x updated: Change the default bind address for AJP to the loopback address
Am 2020-02-05 um 13:30 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/7.0.x by this push:
new 0d633e7 Change the default bind address for AJP to the loopback
address
0d633e7 is described below
commit 0d633e72ebc7b3c242d0081c23bba5e4dacd9b72
Author: Mark Thomas
AuthorDate: Tue Jan 21 13:02:13 2020 +
Change the default bind address for AJP to the loopback address
---
java/org/apache/coyote/ajp/AjpAprProtocol.java | 2 ++
java/org/apache/coyote/ajp/AjpNioProtocol.java | 2 ++
java/org/apache/coyote/ajp/AjpProtocol.java| 2 ++
java/org/apache/tomcat/util/compat/Jre7Compat.java | 19 +++
java/org/apache/tomcat/util/compat/JreCompat.java | 28 ++
webapps/docs/changelog.xml | 4
webapps/docs/config/ajp.xml| 5 +---
7 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/java/org/apache/coyote/ajp/AjpAprProtocol.java
b/java/org/apache/coyote/ajp/AjpAprProtocol.java
index 7b4a825..418d2ca 100644
--- a/java/org/apache/coyote/ajp/AjpAprProtocol.java
+++ b/java/org/apache/coyote/ajp/AjpAprProtocol.java
@@ -20,6 +20,7 @@ import org.apache.coyote.AbstractProtocol;
import org.apache.coyote.Processor;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.util.compat.JreCompat;
import org.apache.tomcat.util.net.AbstractEndpoint;
import org.apache.tomcat.util.net.AprEndpoint;
import org.apache.tomcat.util.net.AprEndpoint.Handler;
@@ -61,6 +62,7 @@ public class AjpAprProtocol extends AbstractAjpProtocol
{
public AjpAprProtocol() {
endpoint = new AprEndpoint();
+endpoint.setAddress(JreCompat.getInstance().getLoopbackAddress());
cHandler = new AjpConnectionHandler(this);
((AprEndpoint) endpoint).setHandler(cHandler);
setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
diff --git a/java/org/apache/coyote/ajp/AjpNioProtocol.java
b/java/org/apache/coyote/ajp/AjpNioProtocol.java
index 741cb22..8668323 100644
--- a/java/org/apache/coyote/ajp/AjpNioProtocol.java
+++ b/java/org/apache/coyote/ajp/AjpNioProtocol.java
@@ -23,6 +23,7 @@ import org.apache.coyote.AbstractProtocol;
import org.apache.coyote.Processor;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.util.compat.JreCompat;
import org.apache.tomcat.util.net.AbstractEndpoint;
import org.apache.tomcat.util.net.NioChannel;
import org.apache.tomcat.util.net.NioEndpoint;
@@ -56,6 +57,7 @@ public class AjpNioProtocol extends
AbstractAjpProtocol {
public AjpNioProtocol() {
endpoint = new NioEndpoint();
+endpoint.setAddress(JreCompat.getInstance().getLoopbackAddress());
cHandler = new AjpConnectionHandler(this);
((NioEndpoint) endpoint).setHandler(cHandler);
setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
diff --git a/java/org/apache/coyote/ajp/AjpProtocol.java
b/java/org/apache/coyote/ajp/AjpProtocol.java
index 50f6f58..69c24eb 100644
--- a/java/org/apache/coyote/ajp/AjpProtocol.java
+++ b/java/org/apache/coyote/ajp/AjpProtocol.java
@@ -22,6 +22,7 @@ import org.apache.coyote.AbstractProtocol;
import org.apache.coyote.Processor;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.util.compat.JreCompat;
import org.apache.tomcat.util.net.AbstractEndpoint;
import org.apache.tomcat.util.net.JIoEndpoint;
import org.apache.tomcat.util.net.JIoEndpoint.Handler;
@@ -57,6 +58,7 @@ public class AjpProtocol extends AbstractAjpProtocol {
public AjpProtocol() {
endpoint = new JIoEndpoint();
+endpoint.setAddress(JreCompat.getInstance().getLoopbackAddress());
cHandler = new AjpConnectionHandler(this);
((JIoEndpoint) endpoint).setHandler(cHandler);
setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
diff --git a/java/org/apache/tomcat/util/compat/Jre7Compat.java
b/java/org/apache/tomcat/util/compat/Jre7Compat.java
index 43513a9..d469f48 100644
--- a/java/org/apache/tomcat/util/compat/Jre7Compat.java
+++ b/java/org/apache/tomcat/util/compat/Jre7Compat.java
@@ -20,6 +20,7 @@ import java.io.OutputStream;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
+import java.net.InetAddress;
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
@@ -56,6 +57,7 @@ class Jre7Compat extends JreCompat {
private static final Method resultSetGetObjectName;
private static final Method statementCloseOnCompletion;
private static final Method statementIsCloseOnCompletion;
+
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and API)
Am 2020-01-28 um 22:56 schrieb Mark Thomas: On 28/01/2020 21:50, Christopher Schultz wrote: Michael, On 1/28/20 3:51 PM, Michael Osipov wrote: Am 2020-01-25 um 12:13 schrieb Mark Thomas: On 23/01/2020 10:29, Michael Osipov wrote: Design questions: * Shall this remain a listener or do we want to introduce a new interface for that? If yes, how should it look like? Given the use cases (could apply at various levels) a LifecycleListener looks like a reasonable design choice to me. I don't see the need for an additional interface (although I could be persuaded if someone else makes an argument for one) * Where can this element be placed? Only in context.xml? Also in server.xml? If yes, at which level are contexts available to be modified? Can this be placed in server.xml at all? LifecycleListener can be placed on most elements so it gives plenty of flexibility. If it remains as a listener, I would be willing to donate my listener to the Tomcat codebase and add support for file:// or other stuff required. Fantastic. Thank you. Take a look at the ConfigFileLoader. All Tomcat config should be loaded through that. From my understanding, the mapping source can be arbitrary: inline, database, file, etc. Agreed. Great, I will pick this up next month and have a look how the ConfigFileLoader works. I hope I can cover at least all current cases. I wonder now which of the components implementing Container should be subject to this listener? Engine, Host, Context? Context is trivial, but the rest? They start before the contexts, I cannot simply say Host#findChildren() at CONFIGURE_START_EVENT. It does not make sense logically. At the moment the Context seems to be the only viable place unless the mappings are held in memory unless all contexts load and query them. This would require to change the Container interface. Comments? I think this only makes sense at the level because the security-roles are all defined at the context-level as well. They may be shared across a bunch of applications, but that's just a coincidence. Mapping this across multiple s won't be a huge burden, given the other options. Another option might be to allow a LifecycleListener to attach some information to a (not sure where that might be) and then you can have /another/ LifecycleListener attached to the . The global one defines the mapping but doesn't actually take any action. The -attached LifecycleListener then looks-up the tree to parent components looking for the mappings, and applies them as the context is being deployed. Seems more work than necessary, though. Just have admins bless each and be done with it. You can add something to a host and then have it do something every time a child (i.e. Context) is added. Looking at the code for MapperListener might give you some ideas of the sort of thing you can do. This is basically what I have assumed to be done. I will go with the simplest approach first: context-only. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat 10: rename language bundles
Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko: ср, 29 янв. 2020 г. в 00:08, Michael Osipov : Folks, I recently worked on some localization issues and noticed that, in my opinion, these JARs are incorrectly named: tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar tomcat-i18n-zh-CN.jar Most people confuse I18N with L10N -- but they are distinct. According to Mozilla [1] Tomcat is internationalized and provides localization with those bundles. As far as I understand that, they should be either tomcat-l10n-.jar or tomcat-nls-.jar [...] Comments? 1. Overall, I am not convinced. I think that for an average foreigner a discussion about what term is better makes little sense. I know people for whom those words are hard to pronounce and are a little obscure. Does changing one "obscure" word with another makes life easier? How? Does it help to reach some wider audience? I think that it would be better to keep it simple (KISS) and continue using the existing historic naming pattern. I am really proud of 20+ years of history of our project. If there are some things there that are not proper [American] English, it just means that there are different people involved with the project, and it is a good sign. (Being too strict about language is a barrier that may reject people.) For those who don't know both, they don't care. For those who know care to make it right/consistent. I see no downsides to make it right. This has nothing to do with American, British, You Name It English. It is simply about consistent naming. 2. In multi-module projects built with Apache Maven, one widely used naming convention is to name artifacts produced by the nested modules as -. E.g., a discussion: https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects I mean that the current artifact names of "tomcat-i18n-" can be interpreted as module "" in a parent project "tomcat-i18n". It means that those artifacts are part of internationalization effort in Tomcat. I don't see how this is related?! Nor did I bring up to do any migration to Maven or its naming scheme. 3. Overall, my vote for this proposal is -0.5. It is not a veto, but I do not like it. So you generally do not object, but don't see a need for? M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-connectors] branch master created (now 254b5bb)
Am 2020-01-30 um 00:24 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark and Michael, On 1/29/20 1:58 PM, Mark Thomas wrote: On 29/01/2020 18:41, Michael Osipov wrote: Am 2020-01-28 um 22:49 schrieb ma...@apache.org: This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git. Why connectors? We have only one, don't we? mod_jk. I assume it to be singular... Because there is more than one. Specifically, mod_jserv, mod_jk, mod_jk2, mod_webap, some of which have and have not been a part of this repository's history. Also, the IIS ISAPI redirector plug-in isn't technically mod_jk, is it? Likewise, the NSAPI redirector (does anyone really use that?!). https://cwiki.apache.org/confluence/display/TOMCAT/Connectors#Connectors - -Q2.1 https://archive.apache.org/dist/tomcat/tomcat-connectors/ Looking at the souce tarball, there are so many confusing things in it: * Jakarta Commons: this is dead * Apache 1.3, 2.0, netscape It needs a lot of cleanup at some point... - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat 10: rename language bundles
Am 2020-01-28 um 22:53 schrieb Mark Thomas: On 28/01/2020 21:52, Christopher Schultz wrote: Michael, On 1/28/20 4:08 PM, Michael Osipov wrote: Folks, I recently worked on some localization issues and noticed that, in my opinion, these JARs are incorrectly named: tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar tomcat-i18n-zh-CN.jar Most people confuse I18N with L10N -- but they are distinct. According to Mozilla [1] Tomcat is internationalized and provides localization with those bundles. As far as I understand that, they should be either tomcat-l10n-.jar or tomcat-nls-.jar NLS (native language support), for those who are familiar with LC_MESSAGES and gettext/libintl or similar. I don't know wether this can be backported to 8.5 or 9.0 due to file renames, but should be an issue with 10. [1] https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/ Comments? +0 This is mostly a matter of style, but you are correct, i18n is inaccurat e. It does mean changing the Maven co-ordinates. While I agree the current naming is wrong, is it wrong enough to break things for upgrading users? Yes, it does mean to change the artifact id, but consider that people will receive them at most as transitive dependency, and the change is proposed for 10 where everthing is still in flux. It is an acceptable change for that version. For 8.5+ it is for the community to decide. I will provide a PR for 10+ only. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat-connectors] branch master created (now 254b5bb)
Am 2020-01-28 um 22:49 schrieb ma...@apache.org: This is an automated email from the ASF dual-hosted git repository. markt pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/tomcat-connectors.git. Why connectors? We have only one, don't we? mod_jk. I assume it to be singular... - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[PROPOSAL] Tomcat 10: rename language bundles
Folks, I recently worked on some localization issues and noticed that, in my opinion, these JARs are incorrectly named: tomcat-i18n-cs.jar tomcat-i18n-de.jar tomcat-i18n-es.jar tomcat-i18n-fr.jar tomcat-i18n-ja.jar tomcat-i18n-ko.jar tomcat-i18n-pt-BR.jar tomcat-i18n-ru.jar tomcat-i18n-zh-CN.jar Most people confuse I18N with L10N -- but they are distinct. According to Mozilla [1] Tomcat is internationalized and provides localization with those bundles. As far as I understand that, they should be either tomcat-l10n-.jar or tomcat-nls-.jar NLS (native language support), for those who are familiar with LC_MESSAGES and gettext/libintl or similar. I don't know wether this can be backported to 8.5 or 9.0 due to file renames, but should be an issue with 10. [1] https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/ Comments? Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [DISCUSS] Mapping internal roles to external ones (web.xml and API)
Am 2020-01-25 um 12:13 schrieb Mark Thomas: On 23/01/2020 10:29, Michael Osipov wrote: Design questions: * Shall this remain a listener or do we want to introduce a new interface for that? If yes, how should it look like? Given the use cases (could apply at various levels) a LifecycleListener looks like a reasonable design choice to me. I don't see the need for an additional interface (although I could be persuaded if someone else makes an argument for one) * Where can this element be placed? Only in context.xml? Also in server.xml? If yes, at which level are contexts available to be modified? Can this be placed in server.xml at all? LifecycleListener can be placed on most elements so it gives plenty of flexibility. If it remains as a listener, I would be willing to donate my listener to the Tomcat codebase and add support for file:// or other stuff required. Fantastic. Thank you. Take a look at the ConfigFileLoader. All Tomcat config should be loaded through that. From my understanding, the mapping source can be arbitrary: inline, database, file, etc. Agreed. Great, I will pick this up next month and have a look how the ConfigFileLoader works. I hope I can cover at least all current cases. I wonder now which of the components implementing Container should be subject to this listener? Engine, Host, Context? Context is trivial, but the rest? They start before the contexts, I cannot simply say Host#findChildren() at CONFIGURE_START_EVENT. It does not make sense logically. At the moment the Context seems to be the only viable place unless the mappings are held in memory unless all contexts load and query them. This would require to change the Container interface. Comments? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat 10: change default certificateKeystoreType and truststoreType from JKS to PKCS12
Am 2020-01-28 um 18:07 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, The subject says it all. Java 9 is changing the default keystore type from JKS to PKCS12 and deprecating the use of JKS. Do we know what version of Java Tomcat 10 will require? I suspect it will be Java 9, so it will match. In any case, PKCS12 is a better format overall and it's very early in the Tomcat 10 lifecycle, so I think it's the right time to make this mov e. It looks like there is no default type for the trust store type (unless javax.net.ssl.trustStoreType has a default value), so I would propose that we also set that default type to PKCS12. Brilliant proposal. +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[DISCUSS] Mapping internal roles to external ones (web.xml and API)
Folks, I'd like to discuss the architecture of BZ 55477 [0], this shall apply to Tomcat 8.5+ only. The feature has been requested several times over time years, being able to map some technical role from a specific store to an application role. E.g., A group SID from AD 'S-1-5-21-126432666-1270913926-3679153413-372575' to role 'User'. What do we have now? * org.apache.catalina.Context.addRoleMapping(String, String) can be called to establish such a link * org.apache.catalina.Context.findRoleMapping(String) queries for such a link My recent changes to the codebase make RealmBase and Wrapper fully support Context#findRoleMapping(). So, it will work automatically. What do we need? * Something which must not be tied to the realm as described in [1] and [2] * Some extension point to inject/call Context#addRoleMapping() I have solved this problem for us at work years ago with a listener [3]. Design questions: * Shall this remain a listener or do we want to introduce a new interface for that? If yes, how should it look like? * Where can this element be placed? Only in context.xml? Also in server.xml? If yes, at which level are contexts available to be modified? Can this be placed in server.xml at all? If it remains as a listener, I would be willing to donate my listener to the Tomcat codebase and add support for file:// or other stuff required. From my understanding, the mapping source can be arbitrary: inline, database, file, etc. [0] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477 [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c14 [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=55477#c15 [3] http://mo-tomcat-ext.sourceforge.net/xref/net/sf/michaelo/tomcat/extras/listeners/PropertiesRoleMappingListener.html Please bear with me since I am a slow responder. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7.0.x end of life
Am 2020-01-14 um 21:56 schrieb Mark Thomas: Hi all, This has been mentioned several times as we have figured out our approach to Jakarta EE 9 and Tomcat 10. I'd like to formally propose that we announce end of life for Tomcat 7.0.x as 31 March 2021. +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=64074
Am 2020-01-14 um 19:55 schrieb Mark Thomas:
On 14/01/2020 18:49, Michael Osipov wrote:
Am 2020-01-14 um 18:09 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new e6f26fa Fix
https://bz.apache.org/bugzilla/show_bug.cgi?id=64074
e6f26fa is described below
commit e6f26fa9d5daf18e994787de65b150f0fc03f29d
Author: Mark Thomas
AuthorDate: Tue Jan 14 17:09:01 2020 +
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=64074
InputStreams for directories obtained from resource URLs now
return a
directory listing consistent with the behaviour of
FileURLConnection.
In addition to restoring the behaviour that was lost as a result
of the
introduction of CachedResourceURLConnection, it expands the
feature to
include packedWARs and to take account of resource JARs.
---
.../catalina/webresources/CachedResource.java | 34 -
.../catalina/webresources/TestCachedResource.java | 57
+-
2 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/webresources/CachedResource.java
b/java/org/apache/catalina/webresources/CachedResource.java
index 712a463..b77862a 100644
--- a/java/org/apache/catalina/webresources/CachedResource.java
+++ b/java/org/apache/catalina/webresources/CachedResource.java
@@ -24,8 +24,12 @@ import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandler;
+import java.nio.charset.Charset;
import java.security.Permission;
import java.security.cert.Certificate;
+import java.text.Collator;
+import java.util.Arrays;
+import java.util.Locale;
import java.util.jar.JarEntry;
import java.util.jar.JarFile;
import java.util.jar.Manifest;
@@ -412,6 +416,22 @@ public class CachedResource implements WebResource {
}
+ /*
+ * Mimics the behaviour of FileURLConnection.getInputStream for a
directory.
+ * Deliberately uses default locale.
+ */
+ private static InputStream buildInputStream(String[] files) {
+ Arrays.sort(files, Collator.getInstance(Locale.getDefault()));
+ StringBuilder result = new StringBuilder();
+ for (String file : files) {
+ result.append(file);
+ // Every entry is followed by \n including the last
+ result.append('\n');
Why didn't you choose System.lineSeparator()?
See the method level comment.
I was afraid of that ;-)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=64074
Am 2020-01-14 um 18:09 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new e6f26fa Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=64074
e6f26fa is described below
commit e6f26fa9d5daf18e994787de65b150f0fc03f29d
Author: Mark Thomas
AuthorDate: Tue Jan 14 17:09:01 2020 +
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=64074
InputStreams for directories obtained from resource URLs now return a
directory listing consistent with the behaviour of FileURLConnection.
In addition to restoring the behaviour that was lost as a result of the
introduction of CachedResourceURLConnection, it expands the feature to
include packedWARs and to take account of resource JARs.
---
.../catalina/webresources/CachedResource.java | 34 -
.../catalina/webresources/TestCachedResource.java | 57 +-
2 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/java/org/apache/catalina/webresources/CachedResource.java
b/java/org/apache/catalina/webresources/CachedResource.java
index 712a463..b77862a 100644
--- a/java/org/apache/catalina/webresources/CachedResource.java
+++ b/java/org/apache/catalina/webresources/CachedResource.java
@@ -24,8 +24,12 @@ import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandler;
+import java.nio.charset.Charset;
import java.security.Permission;
import java.security.cert.Certificate;
+import java.text.Collator;
+import java.util.Arrays;
+import java.util.Locale;
import java.util.jar.JarEntry;
import java.util.jar.JarFile;
import java.util.jar.Manifest;
@@ -412,6 +416,22 @@ public class CachedResource implements WebResource {
}
+/*
+ * Mimics the behaviour of FileURLConnection.getInputStream for a
directory.
+ * Deliberately uses default locale.
+ */
+private static InputStream buildInputStream(String[] files) {
+Arrays.sort(files, Collator.getInstance(Locale.getDefault()));
+StringBuilder result = new StringBuilder();
+for (String file : files) {
+result.append(file);
+// Every entry is followed by \n including the last
+result.append('\n');
Why didn't you choose System.lineSeparator()?
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.5.50
Am 2019-12-07 um 20:54 schrieb Mark Thomas: The proposed Apache Tomcat 8.5.50 release is now available for voting. The major changes compared to the 8.5.49 release are: - Correct multiple regressions in the static resource caching related to using URLs provided for cached resources - Improvements to the Realm interface and implementations - Bug fixes and improvements to the CORS filter Along with lots of other bug fixes and improvements. For full details, see the changelog: https://ci.apache.org/projects/tomcat/tomcat85/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.50/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1241/ The tag is: https://github.com/apache/tomcat/tree/8.5.50 c40ede65ea4fb44b1957ec482f28c7afa71f1b50 +1 Looks good to me! - 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.30
Am 2019-12-07 um 18:24 schrieb Mark Thomas: The proposed Apache Tomcat 9.0.30 release is now available for voting. The major changes compared to the 9.0.29 release are: - Correct multiple regressions in the static resource caching related to using URLs provided for cached resources - Improvements to the Realm interface and implementations - Bug fixes and improvements to the CORS filter Along with lots of other bug fixes and improvements. For full details, see the changelog: https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.30/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1240/ The tag is: https://github.com/apache/tomcat/tree/9.0.30 4fab4cc012d0c31852e957d198cb0549f3d6074c +1 Looks good to me! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: https://bz.apache.org/bugzilla/show_bug.cgi?id=63937 allowCorsPreflight
Am 2019-12-02 um 21:07 schrieb Mark Thomas: On 02/12/2019 19:48, Michael Osipov wrote: Am 2019-12-02 um 18:51 schrieb ma...@apache.org: > This is why I brought up BZ 63938. You see no other way to make it an exact match a not blanket? Not easily, no. You'd essentially have to recreate large chunks of ApplicationFilterFactory. Agreed to the tradeoff, I'd rather would see BZ 63938 fixed in that spirit. --- a/webapps/docs/config/valve.xml +++ b/webapps/docs/config/valve.xml @@ -1201,6 +1201,21 @@ + + Are requests that appear to be CORS preflight requests allowed to + bypass the authenticator as required by the CORS specification. The + allowed values are never, filter and + always. never means that a request will never + bypass authentication even if it appears to be a CORS preflight request. + filter means that a request will bypass authentication if + it appears to be a CORS preflight request and the web application the + request maps to has the CORS I have the feeling that some word is either wrong or missing here: ... and the web application the request maps ... Looks fine to me. Frankly, as a non-English native speaker I do not understand the sentence. Maybe others won't too. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: https://bz.apache.org/bugzilla/show_bug.cgi?id=63937 allowCorsPreflight
Am 2019-12-02 um 18:51 schrieb ma...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new e9430e1 https://bz.apache.org/bugzilla/show_bug.cgi?id=63937
allowCorsPreflight
e9430e1 is described below
commit e9430e1db97d9ffc31d4d4431af92f2511d1b950
Author: Mark Thomas
AuthorDate: Mon Dec 2 14:01:13 2019 +
https://bz.apache.org/bugzilla/show_bug.cgi?id=63937 allowCorsPreflight
Add a new attribute to the standard Authenticator implementations,
allowCorsPreflight, that allows the Authenticators to be configured to
allow CORS preflight requests to bypass authentication as required by
the CORS specification.
---
.../catalina/authenticator/AuthenticatorBase.java | 88 ++
java/org/apache/catalina/filters/CorsFilter.java | 34 +---
java/org/apache/tomcat/util/http/RequestUtil.java | 43 +
.../TestAuthenticatorBaseCorsPreflight.java| 177 +
.../apache/catalina/filters/TestCorsFilter.java| 12 +-
webapps/docs/changelog.xml | 8 +
webapps/docs/config/valve.xml | 93 +--
7 files changed, 413 insertions(+), 42 deletions(-)
diff --git a/java/org/apache/catalina/authenticator/AuthenticatorBase.java
b/java/org/apache/catalina/authenticator/AuthenticatorBase.java
index 76e712b..308b019 100644
--- a/java/org/apache/catalina/authenticator/AuthenticatorBase.java
+++ b/java/org/apache/catalina/authenticator/AuthenticatorBase.java
@@ -33,6 +33,7 @@ import javax.security.auth.message.config.AuthConfigProvider;
import javax.security.auth.message.config.RegistrationListener;
import javax.security.auth.message.config.ServerAuthConfig;
import javax.security.auth.message.config.ServerAuthContext;
+import javax.servlet.DispatcherType;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.http.Cookie;
@@ -53,6 +54,7 @@ import
org.apache.catalina.authenticator.jaspic.CallbackHandlerImpl;
import org.apache.catalina.authenticator.jaspic.MessageInfoImpl;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
+import org.apache.catalina.filters.CorsFilter;
import org.apache.catalina.filters.RemoteIpFilter;
import org.apache.catalina.realm.GenericPrincipal;
import org.apache.catalina.util.SessionIdGeneratorBase;
@@ -63,9 +65,12 @@ import org.apache.coyote.ActionCode;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.ExceptionUtils;
+import org.apache.tomcat.util.descriptor.web.FilterDef;
+import org.apache.tomcat.util.descriptor.web.FilterMap;
import org.apache.tomcat.util.descriptor.web.LoginConfig;
import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
import org.apache.tomcat.util.http.FastHttpDateFormat;
+import org.apache.tomcat.util.http.RequestUtil;
import org.apache.tomcat.util.res.StringManager;
/**
@@ -237,12 +242,22 @@ public abstract class AuthenticatorBase extends ValveBase
*/
protected SingleSignOn sso = null;
+private AllowCorsPreflight allowCorsPreflight = AllowCorsPreflight.NEVER;
+
private volatile String jaspicAppContextID = null;
private volatile Optional jaspicProvider = null;
// - Properties
+public String getAllowCorsPreflight() {
+return allowCorsPreflight.name().toLowerCase();
+}
+
+public void setAllowCorsPreflight(String allowCorsPreflight) {
+this.allowCorsPreflight =
AllowCorsPreflight.valueOf(allowCorsPreflight.trim().toUpperCase());
+}
+
toLowerCase() and toUpperCase() should be locale-agnostic. I bet FILTER
will fail with tr_TR.
public boolean getAlwaysUseSession() {
return alwaysUseSession;
}
@@ -593,6 +608,14 @@ public abstract class AuthenticatorBase extends ValveBase
JaspicState jaspicState = null;
+if ((authRequired || constraints != null) && allowCorsPreflightBypass(request)) {
+if (log.isDebugEnabled()) {
+log.debug(" CORS Preflight request bypassing authentication");
^^
Is that space intended?
+}
+getNext().invoke(request, response);
+return;
+}
+
if (authRequired) {
if (log.isDebugEnabled()) {
log.debug(" Calling authenticate()");
@@ -648,6 +671,64 @@ public abstract class AuthenticatorBase extends ValveBase
}
+protected boolean allowCorsPreflightBypass(Request request) {
+boolean allowBypass = false;
+
+if (allowCorsPreflight !=
Re: [tomcat] branch BZ-63681/8.5.x updated (6be96eb -> a0e8d49)
Am 2019-11-27 um 18:05 schrieb Rémy Maucherat: On Wed, Nov 27, 2019 at 11:28 AM wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a change to branch BZ-63681/8.5.x in repository https://gitbox.apache.org/repos/asf/tomcat.git. This branch is 100% unnecessary. Please delete it instead of keeping spamming me (and others). It is not, 8.5.x requires a different implementation of the issue. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch 7.0.x updated: BZ 63950 - Limit wait time in a test case.
Am 2019-11-23 um 20:57 schrieb kkoli...@apache.org:
This is an automated email from the ASF dual-hosted git repository.
kkolinko pushed a commit to branch 7.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/7.0.x by this push:
new 858f7e7 BZ 63950 - Limit wait time in a test case.
858f7e7 is described below
commit 858f7e7d3d367f4654a95aa31f0ebf57185e12cc
Author: Konstantin Kolinko
AuthorDate: Sat Nov 23 21:05:50 2019 +0300
BZ 63950 - Limit wait time in a test case.
Limit waiting time for endLatch of TestAsyncContextStateChanges#testAsync(),
so that the test does not hang indefinitely in case if expected event does
not happen.
---
.../org/apache/catalina/core/TestAsyncContextStateChanges.java | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/test/org/apache/catalina/core/TestAsyncContextStateChanges.java
b/test/org/apache/catalina/core/TestAsyncContextStateChanges.java
index b9fce86..9c7e723 100644
--- a/test/org/apache/catalina/core/TestAsyncContextStateChanges.java
+++ b/test/org/apache/catalina/core/TestAsyncContextStateChanges.java
@@ -22,6 +22,7 @@ import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
import java.util.concurrent.CountDownLatch;
+import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import javax.servlet.AsyncContext;
@@ -125,11 +126,10 @@ public class TestAsyncContextStateChanges extends
TomcatBaseTest {
if (asyncEnd.isError()) {
client.disconnect();
closeLatch.countDown();
-try {
-endLatch.await();
-} catch (InterruptedException e) {
-// Ignore
-}
+
+Assert.assertTrue(
+"Awaiting endLatch did not complete in 10 seconds",
+endLatch.await(10, TimeUnit.SECONDS));
} else {
client.setUseContentLength(true);
client.readResponse(true);
Doe this fix the issue or the symptom?
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.98
Am 2019-11-22 um 14:19 schrieb Violeta Georgieva: The proposed Apache Tomcat 7.0.98 release is now available for voting. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.98/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1239/ The git tag is: https://github.com/apache/tomcat/tree/7.0.98 fde40d7e0c7a1b0b2423cb84ad220a5d98b65591 The proposed 7.0.98 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 7.0.98 Stable Since Konstantin confirmed my obsevations, I go with BROKEN. Michael - 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.29
Am 2019-11-16 um 19:56 schrieb Mark Thomas: The proposed Apache Tomcat 9.0.29 release is now available for voting. The major changes compared to the 9.0.27 release are: - Improvements to Async error handling - Stricter processing of HTTP headers when looking for specific token values - Fix various issues that could lead to modification to a JSP not being reflected in the served page Along with lots of other bug fixes and improvements. For full details, see the changelog: https://ci.apache.org/projects/tomcat/tomcat9/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-9/v9.0.29/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1236/ The tag is: https://github.com/apache/tomcat/tree/9.0.29 The proposed 9.0.29 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 9.0.29 LGTM, +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Fix test fallout of BZ 63905
Am 2019-11-13 um 17:48 schrieb Christopher Schultz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 11/9/19 05:58, micha...@apache.org wrote:
This is an automated email from the ASF dual-hosted git
repository.
michaelo pushed a commit to branch master in repository
https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this
push: new ccd6518 Fix test fallout of BZ 63905 ccd6518 is
described below
commit ccd6518024ab4f8c0add42eb2b20941a6b237f5d Author: Michael
Osipov AuthorDate: Sat Nov 9 11:35:22 2019
+0100
Fix test fallout of BZ 63905 ---
test/org/apache/coyote/http2/TestHttp2InitialConnection.java | 2
+- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/test/org/apache/coyote/http2/TestHttp2InitialConnection.java
b/test/org/apache/coyote/http2/TestHttp2InitialConnection.java
index 2157eae..a362a19 100644 ---
a/test/org/apache/coyote/http2/TestHttp2InitialConnection.java +++
b/test/org/apache/coyote/http2/TestHttp2InitialConnection.java @@
-127,7 +127,7 @@ public class TestHttp2InitialConnection extends
Http2TestBase { int statusHeaderLength = sm
.getString("errorReportValve.statusHeader", "", "")
.getBytes(StandardCharsets.UTF_8).length; -int len =
1073 + serverInfoLength + statusHeaderLength * 2; +int
len = 708 + serverInfoLength + statusHeaderLength * 2;
Why not fix this properly with:
int len =
org.apache.catalina.util.TomcatCSS.TOMCAT_CSS.getBytes(StandardCharsets.
UTF_8).length
+ serverInfoLength + statusHeaderLength * 2;
??
It's just going to happen again when someone changes the CSS.
I have now pushed a change which should address this properly.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: Fix test fallout of BZ 63905
Am 2019-11-13 um 17:48 schrieb Christopher Schultz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 11/9/19 05:58, micha...@apache.org wrote:
This is an automated email from the ASF dual-hosted git
repository.
michaelo pushed a commit to branch master in repository
https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this
push: new ccd6518 Fix test fallout of BZ 63905 ccd6518 is
described below
commit ccd6518024ab4f8c0add42eb2b20941a6b237f5d Author: Michael
Osipov AuthorDate: Sat Nov 9 11:35:22 2019
+0100
Fix test fallout of BZ 63905 ---
test/org/apache/coyote/http2/TestHttp2InitialConnection.java | 2
+- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/test/org/apache/coyote/http2/TestHttp2InitialConnection.java
b/test/org/apache/coyote/http2/TestHttp2InitialConnection.java
index 2157eae..a362a19 100644 ---
a/test/org/apache/coyote/http2/TestHttp2InitialConnection.java +++
b/test/org/apache/coyote/http2/TestHttp2InitialConnection.java @@
-127,7 +127,7 @@ public class TestHttp2InitialConnection extends
Http2TestBase { int statusHeaderLength = sm
.getString("errorReportValve.statusHeader", "", "")
.getBytes(StandardCharsets.UTF_8).length; -int len =
1073 + serverInfoLength + statusHeaderLength * 2; +int
len = 708 + serverInfoLength + statusHeaderLength * 2;
Why not fix this properly with:
int len =
org.apache.catalina.util.TomcatCSS.TOMCAT_CSS.getBytes(StandardCharsets.
UTF_8).length
+ serverInfoLength + statusHeaderLength * 2;
??
Thanks for raising, but simply this won't work. You have to calculate
the length of:
HTTP Status 400 – Bad Requestbody {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1
{font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}HTTP Status 400 – Bad RequestType Status ReportDescription The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax,
invalid request message framing, or deceptive request routing).Apache Tomcat/9.0.x-dev
What confuses me here for the test, why is
> sm.getString("errorReportValve.statusHeader", "", "")
performed instead of getting the real strings for HTTP 400?!
If you remove all calculatable bits and add them on the code, you have left:
So one should add 196 static bytes.
I will look into it.
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch master updated: BZ 63905: Clean up Tomcat CSS
Am 2019-11-13 um 17:41 schrieb Christopher Schultz:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Michael,
On 11/8/19 17:49, micha...@apache.org wrote:
This is an automated email from the ASF dual-hosted git
repository.
michaelo pushed a commit to branch master in repository
https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this
push: new 69602cb BZ 63905: Clean up Tomcat CSS 69602cb is
described below
commit 69602cb1ef0dc3aa2188a1b3be9fa3a1440cd1b1 Author: Michael
Osipov AuthorDate: Thu Nov 7 22:21:27 2019
+0100
BZ 63905: Clean up Tomcat CSS
Remove duplication in Tomcat CSS and align its usage which applies
to ErrorReportValve, and several servlets. Also update update
incorrect documentation as well. ---
java/org/apache/catalina/servlets/DefaultServlet.java | 16
++-- java/org/apache/catalina/util/TomcatCSS.java
| 16 +++- webapps/docs/changelog.xml
| 3 +++ webapps/docs/config/valve.xml | 5
++--- 4 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/java/org/apache/catalina/servlets/DefaultServlet.java
b/java/org/apache/catalina/servlets/DefaultServlet.java index
c217cf6..2883f5c 100644 ---
a/java/org/apache/catalina/servlets/DefaultServlet.java +++
b/java/org/apache/catalina/servlets/DefaultServlet.java @@ -1815,14
+1815,18 @@ public class DefaultServlet extends HttpServlet {
String rewrittenContextPath = rewriteUrl(contextPath);
// Render the page header -sb.append("\r\n"); +
sb.append("\r\n"); +/* TODO Activate
this as soon as we use smClient with the request locales +
sb.append("\r\n"); +
*/
Thank you for this. Even though it's not yet active, It's good to have
it in there as a reminder for the future.
Do you think it's worth having any \r\n characters in here? Seems like
just a waste of space on the wire.
I would consider two options:
* Remove line breaks, the browser does not need that
* Use a StringWriter/PrintWriter to produce consistent line breaks on
the platforms Tomcat runs
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Tomcat 10: Drop APR Connector
Am 2019-10-09 um 21:40 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Michael On 10/9/19 11:40, Michael Osipov wrote: Am 2019-10-07 um 16:39 schrieb Christopher Schultz: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I recently gave a presentation on locking-down Apache Tomcat[1] and I briefly discussed the "sharp edges" present in Tomcat. Some of them are unnecessarily sharp and may be actually unnecessary. I'm going to make a few proposals to remove functions from Tomcat. Proposal: Remove APR connector Justification: The APR connector was once used to provide superior I/O when compared to the only other available I/O mechanism available in Java: blocking I/O. Specifically, the APR connector allowed Tomcat to wait for keepalive requests on a connection to in a non-blocking fashion which was not possible with Java BIO-based connectors. The introduction of NIO into Java back in Java 1.4 (!!) changed things, and NIO support was added to Tomcat in 6.0. Now that it has had time to mature, the NIO connector is superior to the APR connector in several ways: 1. NIO connector allows non-blocking TLS handshakes 2. NIO connector uses less (Tomcat-owned) native code The first item improves performance and availability and the second item improves stability (and thus availability). The last advantage which (until recently) made the APR connector still very useful was the ability to use the OpenSSL cryptographic library for all cryptographic operations which is measurably higher-performance than those typically provided by the JVM. This last advantage no longer exists since we have a JSSE provider available for OpenSSL using libtcnative. Notes: This proposal does not recommend the removal of libtcnative. Only the removal of the APR connector, the APR lifecycle listener, and the associated native code required to support those components. Though, I have no opion for or against. It has worked very well for me for the last 10+ years on HP-UX for our software. I'd love to get your feedback on NIO+OpenSSL, then. To revive this, why APR is stil important: https://bz.apache.org/bugzilla/show_bug.cgi?id=63916 There is some severe bug making NIO performing very bad. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in on tomcat-trunk
Am 2019-11-09 um 02:24 schrieb Konstantin Kolinko: сб, 9 нояб. 2019 г. в 02:32, Michael Osipov : Am 2019-11-09 um 00:19 schrieb build...@apache.org: The Buildbot has detected a new failure on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4713 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] 69602cb1ef0dc3aa2188a1b3be9fa3a1440cd1b1 Blamelist: Michael Osipov Folks, is there a way to access the build directory on that node or retrigger the build? The failure looks pretty epheremal to me, but want to make sure. http://tomcat.apache.org/ci.html#Buildbot https://ci.apache.org/projects/tomcat/tomcat9/logs/4713/ Thank you, I was looking for this file. The failing test is org.apache.coyote.http2.TestHttp2InitialConnection # testMultipleHostHeaders[0] # testNoHostHeader[0] expected:<...r-[content-length]-[[1131] ... but was:<...r-[content-length]-[[766] The expected size of the page is hardcoded in the test, and your change saved 365 bytes. See the following line in TestHttp2InitialConnection. int len = 1073 + serverInfoLength + statusHeaderLength * 2; Confirmed on two different OSes and JVMs here. Again, thank you! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: buildbot failure in on tomcat-trunk
Am 2019-11-09 um 00:19 schrieb build...@apache.org: The Buildbot has detected a new failure on builder tomcat-trunk while building tomcat. Full details are available at: https://ci.apache.org/builders/tomcat-trunk/builds/4713 Buildbot URL: https://ci.apache.org/ Buildslave for this Build: asf946_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' triggered this build Build Source Stamp: [branch master] 69602cb1ef0dc3aa2188a1b3be9fa3a1440cd1b1 Blamelist: Michael Osipov Folks, is there a way to access the build directory on that node or retrigger the build? The failure looks pretty epheremal to me, but want to make sure. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch BZ-63905/9.0.x created (now de12b4d)
Am 2019-11-07 um 22:44 schrieb Rémy Maucherat: On Thu, Nov 7, 2019 at 10:22 PM wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a change to branch BZ-63905/9.0.x in repository https://gitbox.apache.org/repos/asf/tomcat.git. at de12b4d BZ 63905: Clean up Tomcat CSS This branch includes the following new commits: new de12b4d BZ 63905: Clean up Tomcat CSS The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. As has been voted by the community, please refrain from using branches for trivial reasons. Thanks. What is the trivial reason? Citing yourself: So the community is rather split even if the result leans on the negative side, and many liked the idea of feature branches. I think it's not enough to completely forbid branch use beyond the main release branches. Moreover, no one formally responded to your subsequent proposal. I don't intend to push n commits to master for unfinished work. I am truly convinced that you don't understand the purpose of feature branches in a canonical repo. Your Git bits are limited to tomcat.git only. Please take a look at other Git repos at ASF, e.g., https://github.com/apache/maven/branches/all. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Am 2019-10-18 um 16:12 schrieb Rémy Maucherat: On Fri, Oct 11, 2019 at 4:20 PM Rémy Maucherat wrote: Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [ ] Yes [ ] No Here is a recap of the voting. For the binding votes, we have: Yes: michaelo, ebourg, kkolinko No: remm, schultz, rjung, markt Undecided: fschumacher Thanks to the participants, including the ones with non binding votes who were more in favor of branches. So the community is rather split even if the result leans on the negative side, and many liked the idea of feature branches. I think it's not enough to completely forbid branch use beyond the main release branches. Therefore, I propose resolving this as follows: Branches use should follow a non automatic process: - require a significant amount of work with multiple commits ahead to justify their creation = always a "feature" branch, with the feature being large enough (which is subjective, use common sense) This should have been applied way way earlier. There are too many "fixup", "post fix" commits on master. - get casual community ack before being created (the relevant BZ could get the branch creation request, which should get should get at least one +1 from another committer and of course no vetoes) Seriously? You want me to beg for a cheap branch on an issue I am currently working to solve a problem for the *entire* community? I want to be productive, push intermediate changes and when I think fit, squash them and create the PR with the qualified reviewers assigned. That's what the Apache Maven team and others have been doing for years -- with great success. This pretty much sounds to me that you don't trust your fellow committers doing things right. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Possible bug in Http11Processor/SocketWrapperBase
Am 2019-10-11 um 17:06 schrieb Mark Thomas: On 11/10/2019 13:21, Michael Osipov wrote: Folks, while working on BZ-63835 I have noticed an odd thing and I'd like someone to review whether my code/understanding is wrong or the one already present in Tomcat. we have a total of 100 requests (HTTP/1.1 302). That is consistent with the docs that state there will be maxKeepAliveRequests before the connection is closed. I'd assume the connection to sustain 100 requests and on the n+1 requests to be closed. That assumption is not consistent with the documentation (which has been the same for as long as I can remember). I have just reread the documentation in Tomcat and in HTTPd. They both sound similiar, but why are both differntly implemented? Would you say that bouth have a different intepretation and neither is wrong? I tend to agree with your that if 100 is send 100 is max, and not 100 + 1. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Am 2019-10-12 um 15:57 schrieb Konstantin Kolinko: пт, 11 окт. 2019 г. в 17:21, Rémy Maucherat : Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [x] Yes [ ] No Certainly Yes. We must be able to conduct our business without relying on GitHub and without relying on its pull requests. +1 If we call them not "private" branches, but "feature" branches - your email concerns will be the same, but many projects are using feature branches. I agree that titling a commit as "First draft" is a bad naming. I would like to see more elaborated commit message, with more context in it. If you remember when we were using Subversion, feature branches were used several times. E.g. I used them to backport testing framework to Tomcat 6. It generated a lot of emails, but their Subject line contained the root path of the commit, and in Subversion such path includes a branch name. It is the very same approach. I am working same as before on features under a Bugzilla issue id. This is not intended to be a playground. As a big github user, i expect main repo to not have unofficially supported code. Technically, the only supported code are the official releases that have passed a vote. Anything else is a work in progress. +1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Private branches in the official Tomcat git repository
Am 2019-10-11 um 16:20 schrieb Rémy Maucherat: Hi, This vote is to regulate the use of branches in the official Tomcat repository beyond branches that are approved by the community such as 8.5.x and 7.0.x. It is possible to do development in private branches directly in the official Tomcat repository, as an alternative to using forks and pull requests. Should private branches be allowed in the official Tomcat git repository ? [ ] Yes [ ] No I don't like the term 'private' because everytihing I add to the canonical repo is intended to merged into upstream sooner or later. Purely private stuff must be in a fork anyway. Please redefine. In that case as depicted by me: Yes! - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch BZ-63835/8.5.x created (now 6ff2233)
Am 2019-10-11 um 16:07 schrieb Rémy Maucherat: On Fri, Oct 11, 2019 at 3:46 PM Michael Osipov wrote: Am 2019-10-11 um 15:10 schrieb Rémy Maucherat: On Fri, Oct 11, 2019 at 1:51 PM Michael Osipov wrote: Am 2019-10-11 um 11:32 schrieb Rémy Maucherat: On Fri, Oct 11, 2019 at 10:43 AM Mark Thomas wrote: On 11/10/2019 09:30, micha...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. michaelo pushed a change to branch BZ-63835/8.5.x New features should be implemented against master and then back-ported (assuming the community accepts them). I also (still) prefer either PRs (it allows comments) or in master. This is a first draft, nothing PR worthy. As soon as I see the code working, I will create the PR by then and when approved in general I will add tests and re-request review. So please be patient. For this use I'd recommend using your own forked repository then. Using a branch for that doesn't work for me, it sends way too many emails that are not actually useful to dev to the dev mailing list. I tried for a while, it didn't work, sorry :( I am not really convinced by this and I will tell you why: * Other TLPs have a commits@ for this * The purpose of branches is exactly to work on something * Having it in a fork would take the ability away that people instantly notice my intermediate changes in a canonical location and leave valuable comments as you did guys. No one will look at my fork as long as I don't request it. I rather fix an issue early than two weeks later in the PR. I disagree with this so I will draft and hold a formal vote on this to clarify the rules regarding the use of private branches. Sounds reasonable. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tomcat] branch BZ-63835/8.5.x created (now 6ff2233)
Am 2019-10-11 um 15:20 schrieb Mark Thomas: On 11/10/2019 14:10, Rémy Maucherat wrote: On Fri, Oct 11, 2019 at 1:51 PM Michael Osipov mailto:micha...@apache.org>> wrote: Am 2019-10-11 um 11:32 schrieb Rémy Maucherat: > On Fri, Oct 11, 2019 at 10:43 AM Mark Thomas mailto:ma...@apache.org>> wrote: > >> On 11/10/2019 09:30, micha...@apache.org <mailto:micha...@apache.org> wrote: >>> This is an automated email from the ASF dual-hosted git repository. >>> >>> michaelo pushed a change to branch BZ-63835/8.5.x >> >> New features should be implemented against master and then back-ported >> (assuming the community accepts them). >> > > I also (still) prefer either PRs (it allows comments) or in master. This is a first draft, nothing PR worthy. As soon as I see the code working, I will create the PR by then and when approved in general I will add tests and re-request review. So please be patient. For this use I'd recommend using your own forked repository then. Using a branch for that doesn't work for me, it sends way too many emails that are not actually useful to dev to the dev mailing list. I tried for a while, it didn't work, sorry :( I use upstream so much I should probably reconfigure the names of the remotes in my checkout: origin -> fork upstream -> origin This doesn't feel right. Origin always denotes the repo you cloned from, your fork. So keeping origin and upstream seems fine. I call upstream simply 'apache' in my forked ones and point to gitbox.apache.org. Michael - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
