Off-loading heavy process
My apologies if this is too vague to warrant consideration. In the recent past I managed a naked port, a Selector, a ThreadPoolExecutor and friends (and it worked well enough...) but a dear and knowledgeable friend suggested embedding tomcat and using http.[3] I have that working, one request at a time. Now to get to "production level": I have two distinct types of requests which might be problematic: one is rather large[1] and the other rather prolific[2]. Both types are handled by the same servlet. The data structure is identical, just much less in case[2]. Is it advisable, practical to (re)establish a ThreadPoolExecutor, queue etc as a tomcat accessible "Resource" with JDNI lookup, and have my servlet pass the work off to the Executor's queue? Any pointers appreciated, rjs [1] Comprised of a data block which occasionally has exceeded java max array length, gzipped streams helped a lot. There are few of these requests (22 per project). They last days and can "collide" in terms of when they finish, though by and large they naturally spread themselves out. [2] Given infinite EC2 capacity there would be tens of thousands of jobs started at once. Realistic AWS capacity constraints limit this to hundreds of instances from a queue of thousands. The duration of any instance varies from hours to days. But the payload is simple, under 5K bytes. [3] I'm not entirely confident the original implementation handled all "requests" properly.
Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain
Actually, one incorrect statement in my previous response. testssl.sh didn't report the details of the certificate chain, only that it was broken. I used https://ssllabs.com/ssltest/analyze.html as well, and it reported the specific details of the certificate chain (and that the chain was also broken). Sorry about that. Robert On Wed, Dec 9, 2020 at 9:22 PM Robert Turner wrote: > Thanks Chris for replying. > > I'm pretty sure I'm using the APR connector. Without double-checking how > things are configured... the startup logs show: > > 09-Dec-2020 21:05:25.689 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache > Tomcat Native library [1.2.24] using APR version [1.7.0]. > 09-Dec-2020 21:05:25.689 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR > capabilities: IPv6 [true], sendfile [true], accept filters [false], random > [true]. > 09-Dec-2020 21:05:25.689 INFO [main] > org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL > configuration: useAprConnector [false], useOpenSSL [true] > 09-Dec-2020 21:05:25.704 INFO [main] > org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL > successfully initialized [OpenSSL 1.1.1g 21 Apr 2020] > > On your ECC/RSA separately question: yes, each one works fine by itself. > > I'm not sure what testssl.sh does specifically to verify the chains for > each certificate. I haven't dug into its source yet, but it reports that > the chain for my RSA certificate has the wrong intermediate (and shows the > intermediate for the ECC certificate). So, with minimal examination, to me > it suggests that Tomcat/OpenSSL is not exposing the correct intermediate > certificate when presenting the RSA certificate chain for validation by the > client. > > > I may be able to request the re-issue, but I'm running with fairly > inexpensive certificates, so it might be a bit more of a challenge to get > done, but I could try -- that was going to be my "last resort" approach. > > I'm not clear on it either -- I'm not sure it's a requirement per say from > what I can tell, but maybe just a limitation of the implementation. But I > haven't done enough research (yet) into how TLS negotiation works, or the > implementation of OpenSSL to offer a non-speculative conclusion. I was > sort-of hoping to avoid a 2 or 3 day diversion to learn enough about it all. > > I had been planning on trying the combined certificates in single files to > see if it worked (As it was the only idea that I had based on looking at > the code and how it "saved" the certificates for use), and just kicked it > off the changes while typing this up. (time to check the results) > > With the combined certificates (in order) in the main certificate file, > both certificates now get reported by testssl.sh as: >Chain of trust NOT ok (chain incomplete) > > And when I connect using "openssl s_client -connect :", I see > only the initial certificate in the server response, where normally I would > see the chain listed out up to the root CA. > > So unfortunately, it looks like that doesn't quite work properly either. > > Robert > > On Wed, Dec 9, 2020 at 8:38 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Robert, >> >> On 12/9/20 17:54, Robert Turner wrote: >> > I am trying to configure Tomcat 9.0.37 (or later if I need to) to use >> both >> > an RSA and an ECC certificate for the same host. >> > >> > Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library >> > installed. >> >> Do you know if you are using the APR connector or the NIO(2) connector? >> >> > My configuration is roughly as follows: >> > >> > >> > > >honorCipherOrder="true" >> >ciphers="" >> >hostName="*.blahblah.com"> >> > > certificateKeyFile="conf/blahblah_com_priv.key" >> > certificateFile="conf/blahblah_com.crt" >> > >> > certificateChainFile="conf/blahblah_com.intermediate.crt" >> > type="RSA" >> > /> >> > > > certificateKeyFile="conf/blahblah_com_com-ECC.private.key" >> > certificateFile="conf/blahblah_com-ECC.pem" >> > >> > certificateChainFile="conf/blahblah_com-ECC.intermediate.pem" >> > type="EC" >> > /> >> > >> > >> > >> > The only change I've made was to add the additional Certificate element >> for >> > the ECC certificate (so I believe everything else about our >> configuration >> > is all good. >> > >> > When I run "testssh.sh" against the host, I end up with a failed >> > certificate chain for the RSA certificate. The ECC certificate is all >> fine >> > though, and before adding the ECC certificate, the RSA certificate was >> fine. >> >> Hmm. So if you specify either RSA or EC alone, with the certificate >> chain, all is well (aside from the fact that you can only use one of the >> two certs)? >> >> What does testssh.sh do? >> >> >
Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain
Thanks Chris for replying. I'm pretty sure I'm using the APR connector. Without double-checking how things are configured... the startup logs show: 09-Dec-2020 21:05:25.689 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache Tomcat Native library [1.2.24] using APR version [1.7.0]. 09-Dec-2020 21:05:25.689 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. 09-Dec-2020 21:05:25.689 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] 09-Dec-2020 21:05:25.704 INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.1.1g 21 Apr 2020] On your ECC/RSA separately question: yes, each one works fine by itself. I'm not sure what testssl.sh does specifically to verify the chains for each certificate. I haven't dug into its source yet, but it reports that the chain for my RSA certificate has the wrong intermediate (and shows the intermediate for the ECC certificate). So, with minimal examination, to me it suggests that Tomcat/OpenSSL is not exposing the correct intermediate certificate when presenting the RSA certificate chain for validation by the client. I may be able to request the re-issue, but I'm running with fairly inexpensive certificates, so it might be a bit more of a challenge to get done, but I could try -- that was going to be my "last resort" approach. I'm not clear on it either -- I'm not sure it's a requirement per say from what I can tell, but maybe just a limitation of the implementation. But I haven't done enough research (yet) into how TLS negotiation works, or the implementation of OpenSSL to offer a non-speculative conclusion. I was sort-of hoping to avoid a 2 or 3 day diversion to learn enough about it all. I had been planning on trying the combined certificates in single files to see if it worked (As it was the only idea that I had based on looking at the code and how it "saved" the certificates for use), and just kicked it off the changes while typing this up. (time to check the results) With the combined certificates (in order) in the main certificate file, both certificates now get reported by testssl.sh as: Chain of trust NOT ok (chain incomplete) And when I connect using "openssl s_client -connect :", I see only the initial certificate in the server response, where normally I would see the chain listed out up to the root CA. So unfortunately, it looks like that doesn't quite work properly either. Robert On Wed, Dec 9, 2020 at 8:38 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Robert, > > On 12/9/20 17:54, Robert Turner wrote: > > I am trying to configure Tomcat 9.0.37 (or later if I need to) to use > both > > an RSA and an ECC certificate for the same host. > > > > Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library > > installed. > > Do you know if you are using the APR connector or the NIO(2) connector? > > > My configuration is roughly as follows: > > > > > > >honorCipherOrder="true" > >ciphers="" > >hostName="*.blahblah.com"> > > > certificateFile="conf/blahblah_com.crt" > > > > certificateChainFile="conf/blahblah_com.intermediate.crt" > > type="RSA" > > /> > > > certificateKeyFile="conf/blahblah_com_com-ECC.private.key" > > certificateFile="conf/blahblah_com-ECC.pem" > > > > certificateChainFile="conf/blahblah_com-ECC.intermediate.pem" > > type="EC" > > /> > > > > > > > > The only change I've made was to add the additional Certificate element > for > > the ECC certificate (so I believe everything else about our configuration > > is all good. > > > > When I run "testssh.sh" against the host, I end up with a failed > > certificate chain for the RSA certificate. The ECC certificate is all > fine > > though, and before adding the ECC certificate, the RSA certificate was > fine. > > Hmm. So if you specify either RSA or EC alone, with the certificate > chain, all is well (aside from the fact that you can only use one of the > two certs)? > > What does testssh.sh do? > > > I've dug into the documentation and found this statement with reference > to > > the certificateChainFile parameter: > > > > "Note that when using more than one certificate for different types, they > > all must use the same certificate chain" > > > > So I checked the Git repo, and that was added with a commit comment that > > references the Apache HTTP configuration which states something slightly > > differently: > > > > "But be careful: Providing the certificate chain works only if you are > > using a single RSA or DSA based server certificate. If you are using a > > coupled RSA+DSA
Re: TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain
Robert, On 12/9/20 17:54, Robert Turner wrote: I am trying to configure Tomcat 9.0.37 (or later if I need to) to use both an RSA and an ECC certificate for the same host. Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library installed. Do you know if you are using the APR connector or the NIO(2) connector? My configuration is roughly as follows: The only change I've made was to add the additional Certificate element for the ECC certificate (so I believe everything else about our configuration is all good. When I run "testssh.sh" against the host, I end up with a failed certificate chain for the RSA certificate. The ECC certificate is all fine though, and before adding the ECC certificate, the RSA certificate was fine. Hmm. So if you specify either RSA or EC alone, with the certificate chain, all is well (aside from the fact that you can only use one of the two certs)? What does testssh.sh do? I've dug into the documentation and found this statement with reference to the certificateChainFile parameter: "Note that when using more than one certificate for different types, they all must use the same certificate chain" So I checked the Git repo, and that was added with a commit comment that references the Apache HTTP configuration which states something slightly differently: "But be careful: Providing the certificate chain works only if you are using a single RSA or DSA based server certificate. If you are using a coupled RSA+DSA certificate pair, this will work only if actually both certificates use the same certificate chain. Else the browsers will be confused in this situation." The two statements suggest slightly different things. However the second doesn't suggest that ECC and RSA cannot be combined with different chains. Is there any way to have two different certificate chains for the ECC and RSA certificates and get it working with Tomcat/OpenSSL? (as we don't have certificates with the same chains as our provider seems to use different intermediate CAs for ECC versus RSA). Yeah... it's possible for a CA to use a single cert to sign both EC and RSA keys, but yours appears to use different ones. Any chance you can request a re-issue of one of your certificates using the other type of signing certificate? You will almost certainly have to call and request this from your CA. I don't know why the two certs have to have the same chain when you use SSLCertificateChainFile. Oh, I think it's because there isn't a way to say in httpd which certificate which chain goes with, so there can be only one (effective) directive for that. What happens if you pack everything into (each of) your certificateFile and don't use certificateChainFile *at all*? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TLS on Tomcat: Using ECC and RSA certificates together -- invalid intermediate certificate in chain
I am trying to configure Tomcat 9.0.37 (or later if I need to) to use both an RSA and an ECC certificate for the same host. Platform is Windows 2008 R2, with the Tomcat Native 1.2.24 library installed. My configuration is roughly as follows: The only change I've made was to add the additional Certificate element for the ECC certificate (so I believe everything else about our configuration is all good. When I run "testssh.sh" against the host, I end up with a failed certificate chain for the RSA certificate. The ECC certificate is all fine though, and before adding the ECC certificate, the RSA certificate was fine. I've dug into the documentation and found this statement with reference to the certificateChainFile parameter: "Note that when using more than one certificate for different types, they all must use the same certificate chain" So I checked the Git repo, and that was added with a commit comment that references the Apache HTTP configuration which states something slightly differently: "But be careful: Providing the certificate chain works only if you are using a single RSA or DSA based server certificate. If you are using a coupled RSA+DSA certificate pair, this will work only if actually both certificates use the same certificate chain. Else the browsers will be confused in this situation." The two statements suggest slightly different things. However the second doesn't suggest that ECC and RSA cannot be combined with different chains. Is there any way to have two different certificate chains for the ECC and RSA certificates and get it working with Tomcat/OpenSSL? (as we don't have certificates with the same chains as our provider seems to use different intermediate CAs for ECC versus RSA). Thanks for any suggestions anyone can provide, Robert
[ANN] Apache Tomcat 8.5.61 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.61. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and Java Authentication Service Provider Interface for Containers technologies. Apache Tomcat 8.5.x replaces 8.0.x and includes new features pulled forward from the 9.0.x branch. The notable changes since 8.5.60 include: - Align the behaviour of ServletContext.getRealPath(String path) with the recent clarification from the Servlet specification project. If the path parameter does not start with / then Tomcat processes the call as if / is appended to the beginning of the provided path. - Fix a potential file descriptor leak when WebSocket connections are attempted and fail. Patch provided by Maurizio Adami. - Ensure that the LoadBalancerDrainingValve uses the correct setting for the secure attribute for any session cookies it creates. Based on a pull request by Andreas Kurth. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL?
Thank you George for letting us know on -Dorg.bouncycastle.rsa.allow_multi_use=true" JVM option. Will explore this further and update the document (https://github.com/amitlpande/tomcat-9-fips/blob/master/README.md) appropriately. Albeit reluctantly, we have given in to use BCFIPS (over PKCS12) for our key stores as it is the only format meeting our FIPS requirements. Thanks, Amit -Original Message- From: George Stanchev Sent: Saturday, December 5, 2020 11:17 AM To: Tomcat Users List Subject: RE: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? Chris -Original Message- From: Christopher Schultz Sent: Friday, December 04, 2020 1:20 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Can Tomcat 9 be FIPS compliant without OpenSSL? > With the pluggability of Java's crypto interface, I seriously doubt > Oracle is going to certify a JCE module in the future, esp. with free > 3rd party solutions such as BCFIPS. Is BC actually certified? It seems unlikely to me that a group of volunteers from Australia are going to bother to go through that module-certification process. GS: While the project is open sourced they had a company (Crypto Workshop) that earned a living through paid support and consulting. They were recently acquired (https://www.prnewswire.com/news-releases/primekey-acquires-crypto-workshop-300988188.html). And yes they are certified (https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2768) and currently working on the next certification, expected out next year. > I found it non-trivial and the toolsets to be very specific, and even > after following all instructions from several wikis and web pages I > kept running into issues resulting in overall failure. Yes, the build process for OpenSSL is horrible. I have no idea why they decided to use Perl as their build system. On Windows? I have only tried to build the OpenSSL binary, not the FIPS-compliant module. Having done it on Linux (where it's "easy") I can say I'm glad I'm not responsible for doing it on Windows. GS: Sadly, OpenSSL and the FIPS module built just fine. I forgot the details but it was the ARP or the tcnative itself that failed me. There is also a bug in OpenSSL or tomcat's glue code that if cacerts contain more than a certain number of certificates to fail the handshake with timeout (http://tomcat.10.x6.nabble.com/Client-Cert-TLS-issue-td5090609.html) > Also, keep in mind that OpenSSL 1.0.1 is EOLed and the FIPS module is > only available for that version line. OpenSSL still produces security > fixes to paid support subscribers (we are) but they are not available > for the general public. OpenSSL 3.0 will have a refreshed re-certified > FIPS module but it is not due until later next year, so for now > general public is left hanging with the last public version of > 1.0.1+FIPS. :( This is why we can't have nice things. > The workaround could be to use a different password based key > derivation function - PBKDF2. However, there is nothing in the PKCS12 > spec that allows to encode another algorithm OID in MacData. In > essence, you cannot use any other algorithm other than the one defined > in spec which is not FIPS compliant. And something which is ironically FIPS-compliant is to use a PEM file with no protection whatsoever. GS: Well, the keys in the PEM files are still encrypted but you're right no protection of the overall container like in BCFKS or PKCS12 George B CB [ X ܚX KK[XZ[ \ \ ][ X ܚX P X ] \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ \ \ Z[ X ] \X K ܙ B - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Updates to POEditor.com
Nice! So we can edit in POEditor without worrying about any escaping issue then. That's great. Cheers, Woonsan On Tue, Dec 8, 2020 at 4:49 AM Mark Thomas wrote: > > All, > > As you are probably aware, the Apache Tomcat project uses POEditor.com > to manage the i18n translations used by the project. > > The POEditor team have implemented a change that means it is no longer > necessary for us to escape single quotes when using them in translated > strings. The appropriate escaping is now added automatically when the > strings are exported. The current translations have been updated to > reflect this. > > We have seen an immediate benefit of this change. I am currently in the > middle of re-exporting the translations from POEditor.coma and importing > them into the Tomcat source code to confirm that POEDitor's automatic > update didn't break anything. So far I have found no errors and a > handful of instances where we were not escaping correctly that have been > automatically corrected. > > Remember, anyone can create a POEditor.com account and start helping > with the translations. > > https://poeditor.com/projects/view?id=221603 > > Thanks, > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3
Thank you Stefan, Chris for the inputs. As I understood from our security experts, there is no moving away from /dev/random (anything else isn't (strongly) FIPS compliant) for us. Thanks, Amit -Original Message- From: Christopher Schultz Sent: Wednesday, December 2, 2020 10:29 AM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Bouncy Castle FIPS on RHEL 7.3 Stefan, On 11/30/20 19:17, Stefan Mayr wrote: > Hi, > > Am 30.11.2020 um 17:09 schrieb Amit Pande: >> I guess I will have to investigate the RHEL 7.3 entropy issue separately >> (possibly as hobby project) and look for other options to make progress. >> >> I still find it odd that something related to randomness (entropy >> generation) is so consistent (the slowness is equally slow or more on >> multiple RHEL 7.3 systems I have, maybe I need to look for machines from >> different data center or a physical 7.3 server). >> >> And yes, the 10 year certificate validity is just for testing >> purposes. >> >> Thank you for your inputs. Indeed helpful in evaluating our choices. >> >> Thanks, >> Amit > > you might have a look at rng-tools (rngd) or haveged to boost your > entropy pool. > > We use haveged in a VMware virtualized environment and this reduces a > plain tomcat startup from multiple minutes to just a few secondes. > > I think Red Hat preferes rngd but there should be some articles on > access.redhat.com to help you depending on the used hypervisor. I would think long and hard about whether or not you want to use any of these tools. There are already ways to get "a lot of entropy really quickly" from the Linux kernel; specifically, /dev/urandom. The whole point of both /dev/random and /dev/urandom existing side by side is so that the application can pick whether it wants "high quality entropy" (by using /dev/random) or "good enough randomness" (by using /dev/urandom). Tools like haveged and rngd basically make /dev/random behave like /dev/urandom so the application can never have "high quality entropy" even when it asks for it. Have a look at this discussion on security.stackexchange to get you started down the path to paranoia: https://security.stackexchange.com/questions/34523 My question has always been "if these things are both safe and a good idea, why does the Linux kernel not implement them directly?" There must be a reason why the kernel devs have decided not to "speed up" /dev/random using the techniques used by both haveged and rngd. Maybe their argument is essentially "you can always just use haveged/rngd" but my guess is there is a more fundamental reason for not adopting these techniques directly in the kernel. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 9.0.41 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.41. Apache Tomcat 9 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 9.0.41 is a bugfix and feature release. The notable changes compared to 9.0.40 include: - Align the behaviour of ServletContext.getRealPath(String path) with the recent clarification from the Servlet specification project. If the path parameter does not start with / then Tomcat processes the call as if / is appended to the beginning of the provided path. - Fix a potential file descriptor leak when WebSocket connections are attempted and fail. Patch provided by Maurizio Adami. - Ensure that the LoadBalancerDrainingValve uses the correct setting for the secure attribute for any session cookies it creates. Based on a pull request by Andreas Kurth. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-9.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 10.0.0 (beta) available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.0.0 (beta). Apache Tomcat 10 is an open source software implementation of the Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language, Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations specifications. Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later. A migration tool is under development to aid this process. Apache Tomcat 10.0.0 (beta) is a beta release of the 10.0.x branch. The notable changes compared to 10.0.0-M10 include: - The Jakarta EE specifications are now final. Tomcat passes the TCKs apart from a number of expected failures that don't impact specification compliance. - The APR/Native AJP and HTTP connectors have been deprecated. Tomcat Native will continue to be used to support OpenSSL use with NIO and NIO2. - Align the behaviour of ServletContext.getRealPath(String path) with the recent clarification from the Servlet specification project. If the path parameter does not start with / then Tomcat processes the call as if / is appended to the beginning of the provided path. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 7.0.x, 8.5.x and 9.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
