Re: 9.0.70 / 9.0.71 regression?
Thanks for updating - sorry I didn't get a chance to run it down more. I should be able to do a test in our SSO enabled env this next week with 9.0.73. Dan On 2/27/23 4:06 AM, Mark Thomas wrote: Looks like this is the issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=66488 That you only see the problem when using the SSO layer is consistent with our understanding of that bug. Mark On 16/02/2023 08:37, Mark Thomas wrote: On 16/02/2023 00:42, Dan Armbrust wrote: Are there any known regressions / open issues with 9.0.70 or 9.0.71 that could cause something like the below? The closest I can think of is this: https://bz.apache.org/bugzilla/show_bug.cgi?id=66388 but it is fixed in 9.0.71 and I'd expect it to impact resource lookup (i.e.finding files on disk) but not the request URI since the URL class isn't used got processing the request URI. It would be good to track this down ASAP as we are about to start the next round of releases. Mark We encountered a very odd issue today, where after upgrading the version of spring-boot for one of our rest microservices (and getting a newer tomcat) it stopped processing our calls properly. But only when it was deployed in an env where the requests were going thru a SSO authentication layer first, and having a number of extra headers added to the request. When we tested locally, in an env without the SSO filtering, we didn't see the issue. It was a very odd problem, it presented to the end user as simply getting 404 errors back from the service. Tomcat was indeed sending 404 errors - but our integrated monitoring (datadog) was not even showing us the proper requests coming in - instead, each request that arrived came across with some partial (random) URL, which then didn't match any of our services, and was sent back as a 404. We haven't yet done any further debugging about where in the tomcat stack the request was being completely corrupted. I also haven't isolated if it was 9.0.71 or 9.0.70 - 9.0.69 works, and 9.0.71 fails. Thanks, Dan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 10.1.7 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 10.1.7. 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. 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. This conversion is performed using the Apache Tomcat migration tool for Jakarta EE tool which is also available as a separate download for off-line use. The notable changes compared to 10.1.6 include: - Correct a regression introduced in the fix for bug 66196 that meant that the HTTP headers and/or request line could get corrupted (one part overwriting another part) within a single request. - Revert the switch to using the ServiceLoader mechanism to load the custom URL protocol handlers that Tomcat uses. The original system property based approach has been restored. - Restore inline state after async operation in NIO2, to account the fact that unexpected exceptions are sometimes thrown by the implementation. Patch submitted by zhougang. - Provide a more appropriate response (501 rather than 400) when rejecting an HTTP request using the CONNECT method. - Add support for txt: and rnd: rewrite map types from mod_rewrite. Based on a pull request provided by Dimitrios Soumis. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-10.1-doc/changelog.html Downloads: http://tomcat.apache.org/download-10.cgi Migration guides from Apache Tomcat 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
[ANN] Apache Tomcat 8.5.87 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.5.87. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language, Java WebSocket and JASPIC technologies. Apache Tomcat 8.5.87 is a bugfix and feature release. The notable changes compared to 8.5.86 include: - Correct a regression introduced in the fix for bug 66196 that meant that the HTTP headers and/or request line could get corrupted (one part overwriting another part) within a single request. - Provide a more appropriate response (501 rather than 400) when rejecting an HTTP request using the CONNECT method. - Add support for txt: and rnd: rewrite map types from mod_rewrite. Based on a pull request provided by Dimitrios Soumis. Along with lots of other bug fixes and improvements. Please refer to the change log for the complete list of changes: https://tomcat.apache.org/tomcat-8.5-doc/changelog.html Downloads: https://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 7.x and 8.0: https://tomcat.apache.org/migration.html Please note that Tomcat 8.5.x will reach End-of-life (EOL) on 31 March 2024. For more information please visit https://tomcat.apache.org/tomcat-85-eol.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: sslHostConfig and ciphers
Thank you!!!
Thanks,
Sent with BlackBerry Work (www.blackberry.com)
From: "Thomas Hoffmann (Speed4Trade GmbH)"
Sent: Mar 4, 2023 1:22 AM
To: Tomcat Users List
Subject: AW: sslHostConfig and ciphers
Hello,
this message originates from your used java. It's not from tomcat.
Java doesn't know this cipher-suite or is disabled in java.security
You can list the supported ciphers via some code lines like
https://urldefense.com/v3/__https://stackoverflow.com/questions/9333504/how-can-i-list-the-available-cipher-algorithms__;!!F9svGWnIaVPGSwU!ok1eVR9QoczE-D4sspGE5zZh3h7aTnNIrKfVfkKUC4CSWI-99BHQNKZNO1VwWMhDzKjxpRQIsilgijmwV8_swl6-GicjRiAnIId8fctCkh9Xjg$
Greetings, Thomas
> -Ursprüngliche Nachricht-
> Von: jonmcalexan...@wellsfargo.com.INVALID
>
> Gesendet: Freitag, 3. März 2023 18:38
> An: users@tomcat.apache.org
> Betreff: sslHostConfig and ciphers
>
> Ok, I don't know if I'm doing something wrong, or if I'm just not reading the
> output correctly.
>
> I have JSSE connector using sslHostConfig and in there I have defined ciphers,
> as below:
>
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150"
> maxHttpHeaderSize="16384"
> compression="on"
> scheme="https"
> SSLEnabled="true"
> secure="true"
> defaultSSLHostConfigName="test.test">
> hostName="test.test"
> protocols="TLSv1.2"
> ciphers="TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH
> _AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
> TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_C
> CM,TLS_ECDHE_ECDSA_WITH_AES_256_CCM,TLS_DHE_RSA_WITH_AES_256_
> CCM_8,
> TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,TLS_DHE_RSA_WITH_AES_128_G
> CM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_1
> 28_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_CCM,
> TLS_ECDHE_ECDSA_WITH_AES_128_CCM,TLS_DHE_RSA_WITH_AES_128_CCM
> _8,TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,
> TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_
> CHACHA20_POLY1305_SHA256,
> TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256"
> certificateKeystoreFile=""
> certificateKeystorePassword ="${keystore.pass}"
> certificateKeyPassword="${keystore.pass}"
> certificateKeyAlias=""
> />
>
>
>
> However, if I enable ssl debugging, I am getting the following messages in my
> catalina.out file.
>
> 03-Mar-2023 16:43:22.120 INFO [main] org.apache.coyote.AbstractProtocol.init
> Initializing ProtocolHandler ["https-jsse-nio-9443"]
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.146
> UTC|SSLContextImpl.java:425|System property jdk.tls.client.cipherSuites is set
> to 'null'
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.150
> UTC|SSLContextImpl.java:425|System property jdk.tls.server.cipherSuites is set
> to 'null'
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.161
> UTC|SSLCipher.java:438|jdk.tls.keyLimits: entry = AES/GCM/NoPadding
> KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.201
> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.201
> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
> TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.202
> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.202
> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.202
> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.202
> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.203
> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.212
> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.212
> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.213
> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
> TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.213
> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.213
> UTC|SSLContextImpl.java:408|Ignore unsupported cipher suite:
> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|FINE|01|main|2023-03-03 16:43:22.213
> UTC|SSLContextImpl.java:399|Ignore disabled cipher suite:
> SSL_RSA_WITH_3DES_EDE_CBC_SHA
> javax.net.ssl|ALL|01|main|2023-03-03 16:43:22.214
Re: Tomcat 9.0.71 Anomalies
On 03/03/2023 20:19, jonmcalexan...@wellsfargo.com.INVALID wrote:
Hi Mark,
On the slowness, this is when they are retrieving random .js files from the
exploded war file after deployment.
To clarify, these are .js files loaded directly from the file system?
They are not packaged in a JAR file?
It's taking an a long
amount of time. Some of these are quite large, like 2MB or more. When the
issue shows, doing a curl we get to here and then it pauses for some time
before it feeds back the data.
* Trying **.**.**.**:8443...
* TCP_NODELAY set
* Connected to server port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 /
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject:
* start date:
* expire date:
* issuer:
* SSL certificate verify result: unable to get local issuer certificate (20),
continuing anyway.
GET HTTP/1.1
Host:
User-Agent: curl/7.65.3
Accept: */*
And it just hangs out here before finally getting the requested file.
How repeatable is this?
How long does it hang before delivering content? Is it always the same
or does it vary.
Which connector are you using?
What Tomcat version did you upgrade from?
How does the problem before the upgrade compare to the problem after the
upgrade?
What component is serving the content? Is it Tomcat's default servlet or
is it something else?
When it happens, take 3 thread dumps a few seconds apart. The aim is to
figure out why it is hanging.
In looking at the catalina.out log file, I am not seeing any
errors/stack-traces.
Any ideas as to what may be causing this?
Not at the moment. The information requested above should at least
narrow down which parts we need to think about.
Mark
Thank you,
Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His
Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions
8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508
jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are
not the addressee or authorized to receive this for the addressee, you must not
use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
-Original Message-
From: Mark Thomas
Sent: Friday, March 3, 2023 1:32 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.71 Anomalies
On 02/03/2023 21:54, jonmcalexan...@wellsfargo.com.INVALID wrote:
Hello gentle beings,
I have a couple of application teams having issues since getting upgraded to
Tomcat 9.0.71.
Upgrading from which Tomcat version?
The main one has to do with an application that has run fine in the past is
now exceeding max cursors with their Oracle Database datasource. They are
using spring framework to control the Database operations. Here is what
their resource looks like:
type="javax.sql.DataSource"
maxTotal="100" maxIdle="30" maxWaitMillis="15000"
username="${datasource.fm.username}"
password="${datasource.fm.password}"
driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@(Description=(CONNECT_TIMEOUT=10)(RETRY_COUN
T=3)(ADDRESS_LIST=(LOAD_BALANCE=on)(FAILOVER=ON)(ADDRESS=(PROT
OCOL=tcp)(HOST=***)(PORT=3203))(ADDRESS=(PROTOCOL=
tcp)(HOST=*)(PORT=3203)))(CONNECT_DATA=(SERVICE
_NAME=ceofm_u)))"/>
Here is an error from the log file:
[3/2/2023 1:50 PM] Burgos, Maria D.:
here is the error in catalina.out
02-Mar-2023 13:05:30.944 SEVERE [https-jsse-nio-28443-exec-8]
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for
servlet [f***servlet] in context with path [/f***] threw exception [Request
processing failed; nested exception is
com.wellsfargo.fms.common.exception.FMSException] with root cause
com.wellsfargo.f**.common.exception.F**Exception
at
org.springframework.jdbc.core.JdbcTemplate.translateException(JdbcTempl
ate.java:1542)
at
org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:66
7)
Any chance we can see a root cause for that? Something from the JDBC
driver?
The other team is having performance issues when using static .jar
resources in their war file. One part
Re: 9.0.73 change log
Fixed.
Thanks for letting us know.
Mark
On 03/03/2023 22:56, Adam Rauch wrote:
Thanks, Tomcat team, for cranking out another release!
I noticed a minor discrepancy on the main website home page
(https://tomcat.apache.org/). In the "Tomcat 9.0.73 Released" section,
"Tomcat 9 changelog" links to the 9.0.71 bookmark
("#Tomcat_9.0.71_(remm)") instead of the 9.0.73 bookmark.
Thanks,
Adam
-
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
