Re: Tomcat 11 - minimum Java version
On 16/05/2023 18:12, koteswara Rao Gundapaneni wrote: To service the SSL tomcat end users are now engaged mostly with HTTPD SERVER and IBM HTTPD I don't think that is the case. Yes, lots of Tomcat instances are behind reverse proxies and yes, lots of those reverse proxies are terminating TLS but there is still a high demand for Tomcat to be able to terminate TLS since: - Some users are happy running Tomcat without a reverse proxy. - Many users use Tomcat in environments (e.g. banking) where it is a requirement that the channel between the reverse proxy and Tomcat uses TLS. Also, if I had to list the most commonly used proxies, I don't think IBM's HTTP server would be on that list. httpd, ATS, NginX and F5 are the first few that come to mind. If we look at the c,c++,etc API vendors they rarely change thier Products production at user level Yes, but. The timescales were are talking about here are large - at least for software. The average Tomcat release is supported for 10 years. Factor in LTS policies of Linux distributions such as Debian and Ubuntu and you can easily get to timescales in the 15-20 year range. The OpenSSL API that Tomcat Native uses has been very stable over an extended time frame but even with that we have had to use #ifdef directives and the like to have a single code base that can be used with multiple versions - often related to access to new features. Once we switch to using Panama, we are going to have to figure out how to handle this. My primary concern is new features that depend on API calls only present in newer OpenSSL versions. Mark On Sat, May 13, 2023 at 1:48 AM Mark Thomas wrote: On 12/05/2023 22:24, Rémy Maucherat wrote: On Wed, Jan 11, 2023 at 12:23 PM Mark Thomas wrote: We would normally make Java 21 the minimum Java version. Given that Java 21 is still in EA, I don't plan to do that yet. Since the update to Java 21 has now been made and seems to make everyone happy, I would like to discuss Panama. - Panama as it is right now removes the need for tomcat-native 2.0. It is stable, fast enough, works out of the box, is much much better for cloud environments (no funny custom binary to add, only the usual Java), and so on. Actually, all of these statements were already true with Java 17, although the API was a bit rougher. Unfortunately at the moment, it is still preview in Java 21. - It is possible to include the support right now, but since the API would change in Java 22, then Tomcat 11 (or at least that feature) would only target Java 21. Compilation would have to occur on Java 21. - Support for Java 21 ends in 2028. This means then there would be a needed API update to Java LTS.next, dropping support for Java 21 (for that feature), and causing a more complex build (targeting Java 21 with a newer Panama API would cause the compiler to scream). - Multi release JARs are an option, but this is annoying as it would require multiple Java versions to build Tomcat (since it is a preview API), then assemble the multi release JAR. Not looking too good ... Given all this, there are two main options: A) (unfortunately) *not* including the Panama support until it is non preview. Once this happens, then my proposal would be to update the minimum build Java version (not runtime !) for Tomcat 11, add the Panama "final API" support, and use the release option to still target 21 (except for the Panama feature classes, of course, which would be compiled separately). Also as a consequence tomcat-native 2 would have to be supported for the entire lifecycle of Tomcat 11. B) Add full support using Java 21, drop tomcat-native. Once Java LTS.next is released towards the end of 2025 (with non preview Panama, hopefully), update to use the new API. Users of OpenSSL will have to move to Java LTS.next Although I would like B), A) seems more reasonable and in line with our support practices. Comments ? Is there any chance Panama will come out of preview in Java 21? OpenSSL supports versions for less time than the typical support period for a major Tomcat version (10 years). And then you have the Linux distributions that have specific OpenSSL versions and their support periods. With Tomcat Native we have been able to manage this reasonably well without too much maintenance burden for us. How would this work with different versions of OpenSSL? Is it possible to support multiple OpenSSL versions? Of the two options you present, I agree that option A is more in-line with how we typically do things (as much as I would like to say goodbye to native code). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.or
[VOTE][RESULT] Release Apache Tomcat 10.1.9
All, The following votes were cast: +1: markt, isapir, remm, lihan, schultz Non-binding: Dimitris Soumis There were no other votes cast, the vote therefore passes. I will begin the release process shortly. Thanks to everyone who contributed to this release. Thanks, -chris The proposed Apache Tomcat 10.1.9 release is now available for voting. The notable changes compared to 10.1.8 are: - Many improvements to the JSON access log valve. - Deprecate support for the HTTP Connector settings rejectIllegalHeader and allowHostHeaderMismatch and reject HTTP headers without names. - Add a RateLimitFilter which can be used to mitigate DoS and Brute Force attacks. For full details, see the change log: https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 without changes. Java EE applications designed for Tomcat 9 and earlier may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat will automatically convert them to Jakarta EE and copy them to the webapps directory. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.9/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1435 The tag is: https://github.com/apache/tomcat/tree/10.1.9 5d45c1a9359c2298d7140c1ca90cb8c43809a168 The proposed 10.1.9 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 10.1.9 - 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.89
All, I currently only have 2 total votes for this release. Is anyone else able to vote? Thanks, -chris On 5/9/23 13:38, Christopher Schultz wrote: The proposed Apache Tomcat 8.5.89 release is now available for voting. The notable changes compared to 8.5.88 are: - Many improvements to the JSON access log valve. - Deprecate support for the HTTP Connector settings rejectIllegalHeader and allowHostHeaderMismatch and reject HTTP headers without names. - Add a RateLimitFilter which can be used to mitigate DoS and Brute Force attacks. Along with lots of other bug fixes and improvements. For full details, see the changelog: https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.89/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1436 The tag is: https://github.com/apache/tomcat/tree/8.5.89/ da91bd19ef2cb34a96e4ad04749dfc97c941db87 The proposed 8.5.89 release is: [ ] Broken - do not release [ ] Stable - go ahead and release as 8.5.88 (stable) - 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.89
Am 09.05.23 um 19:38 schrieb Christopher Schultz: The proposed Apache Tomcat 8.5.89 release is now available for voting. The notable changes compared to 8.5.88 are: - Many improvements to the JSON access log valve. - Deprecate support for the HTTP Connector settings rejectIllegalHeader and allowHostHeaderMismatch and reject HTTP headers without names. - Add a RateLimitFilter which can be used to mitigate DoS and Brute Force attacks. Along with lots of other bug fixes and improvements. For full details, see the changelog: https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.89/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1436 The tag is: https://github.com/apache/tomcat/tree/8.5.89/ da91bd19ef2cb34a96e4ad04749dfc97c941db87 The proposed 8.5.89 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.88 (stable) +1 to release. Tested on RHEL 6, 7 and 8, SLES 11, 12 and 15, Solaris 10 and 11 with a variety of JVM versions (1.7.0, 1.8.0, 11, 17, 20, 21) and vendors (Adoptium, Azul Zulu, Oracle, RedHat). Also tested with tcnative 1.2.36 and 2.0.3 using OpenSSL 1.1.1t, 3.0.8 and 3.1.0. The new RateLimitFilter fails its test, but there was a post-8.5.89 commit that changes the test. Haven't checked, whether that fixed it. Thanks for RM, Rainer - 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.89
Rainer, On 5/17/23 09:19, Rainer Jung wrote: Am 09.05.23 um 19:38 schrieb Christopher Schultz: The proposed Apache Tomcat 8.5.89 release is now available for voting. The notable changes compared to 8.5.88 are: - Many improvements to the JSON access log valve. - Deprecate support for the HTTP Connector settings rejectIllegalHeader and allowHostHeaderMismatch and reject HTTP headers without names. - Add a RateLimitFilter which can be used to mitigate DoS and Brute Force attacks. Along with lots of other bug fixes and improvements. For full details, see the changelog: https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.89/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1436 The tag is: https://github.com/apache/tomcat/tree/8.5.89/ da91bd19ef2cb34a96e4ad04749dfc97c941db87 The proposed 8.5.89 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 8.5.88 (stable) +1 to release. Tested on RHEL 6, 7 and 8, SLES 11, 12 and 15, Solaris 10 and 11 with a variety of JVM versions (1.7.0, 1.8.0, 11, 17, 20, 21) and vendors (Adoptium, Azul Zulu, Oracle, RedHat). Also tested with tcnative 1.2.36 and 2.0.3 using OpenSSL 1.1.1t, 3.0.8 and 3.1.0. The new RateLimitFilter fails its test, but there was a post-8.5.89 commit that changes the test. Haven't checked, whether that fixed it. Thanks for RM, Of course. Thanks for the vote ;) -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
Mark, On 5/17/23 04:52, Mark Thomas wrote: On 16/05/2023 18:12, koteswara Rao Gundapaneni wrote: To service the SSL tomcat end users are now engaged mostly with HTTPD SERVER and IBM HTTPD I don't think that is the case. Yes, lots of Tomcat instances are behind reverse proxies and yes, lots of those reverse proxies are terminating TLS but there is still a high demand for Tomcat to be able to terminate TLS since: - Some users are happy running Tomcat without a reverse proxy. - Many users use Tomcat in environments (e.g. banking) where it is a requirement that the channel between the reverse proxy and Tomcat uses TLS. +1 Nobody should be using unencrypted network connections for anything they care about. Even on a "trusted" network. Also, if I had to list the most commonly used proxies, I don't think IBM's HTTP server would be on that list. httpd, ATS, NginX and F5 are the first few that come to mind. If we look at the c,c++,etc API vendors they rarely change thier Products production at user level Yes, but. The timescales were are talking about here are large - at least for software. The average Tomcat release is supported for 10 years. Factor in LTS policies of Linux distributions such as Debian and Ubuntu and you can easily get to timescales in the 15-20 year range. The OpenSSL API that Tomcat Native uses has been very stable over an extended time frame but even with that we have had to use #ifdef directives and the like to have a single code base that can be used with multiple versions - often related to access to new features. Once we switch to using Panama, we are going to have to figure out how to handle this. My primary concern is new features that depend on API calls only present in newer OpenSSL versions. The Java components can query the OpenSSL API level from the library and make decisions based on that. It won't be a compile-time decision any more, which IMO is actually a good thing. -chris - 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.89
> On May 10, 2023, at 01:38, Christopher Schultz > wrote: > > The proposed Apache Tomcat 8.5.89 release is now available for voting. > > The notable changes compared to 8.5.88 are: > > - Many improvements to the JSON access log valve. > > - Deprecate support for the HTTP Connector settings rejectIllegalHeader > and allowHostHeaderMismatch and reject HTTP headers without names. > > - Add a RateLimitFilter which can be used to mitigate DoS and Brute > Force attacks. > > Along with lots of other bug fixes and improvements. > > For full details, see the changelog: > https://nightlies.apache.org/tomcat/tomcat-8.5.x/docs/changelog.html > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.89/ > > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1436 > > The tag is: > https://github.com/apache/tomcat/tree/8.5.89/ > da91bd19ef2cb34a96e4ad04749dfc97c941db87 > > The proposed 8.5.89 release is: > [ ] Broken - do not release > [X ] Stable - go ahead and release as 8.5.88 (stable) +1 Han > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 11 - minimum Java version
17 May 2023 20:37:01 Christopher Schultz : On 5/17/23 04:52, Mark Thomas wrote: Once we switch to using Panama, we are going to have to figure out how to handle this. My primary concern is new features that depend on API calls only present in newer OpenSSL versions. The Java components can query the OpenSSL API level from the library and make decisions based on that. It won't be a compile-time decision any more, which IMO is actually a good thing. Ah, I didn't know that. Nice. I need to read up on Panama. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66602] TCP abnormal shutdown during pressure testing based on HTTP2 (h2c)
https://bz.apache.org/bugzilla/show_bug.cgi?id=66602 --- Comment #2 from ledefe <517893...@qq.com> --- Didn't anyone reply？ -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
