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

Reply via email to