[ANN] Apache Tomcat 9.0.106 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.106. 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.106 is a bugfix and feature release. The notable changes compared to 9.0.105 include: - Provide finer grained control of multi-part request processing via two new attributes on the Connector element. - Mark the JSP wrapper for reload after a failed compilation. 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-9.0-doc/changelog.html Downloads: https://tomcat.apache.org/download-90.cgi Migration guides from Apache Tomcat 7.x and 8.x: https://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
[tomcat] Odd behavior enumerating http headers
Greetings
I'm running tomcat v9.0.105 with a CXF based SOAP service (you know, the
old school JAXWS services). Within that service, I had a need to retrieve a
specific http header and i've been running into some inconsistent results.
The tomcat server is sitting behind a nginx proxy if that matters.
Sometimes the header was there, sometimes it wasn't. It was more consistent
if I send the header twice with different casing. x-forwarded-for vs
X-Forwarded-For. (issue 1)
In order to troubleshoot the inconsistency, i wrote a little routine to
simple get the servlet request, get the header names, enumerate them and
print all the keys and values to the log file for troubleshooting. Then i
ran into an even stranger problem... sometimes, but not always, I'm getting
a NPE being thrown from tomcat code and I honestly have no idea why (issue
2)
First the stack trace for (issue 2)...
at
org.apache.tomcat.util.http.ValuesEnumerator.findNext(MimeHeaders.java:509)
[tomcat-coyote.jar:9.0.105]
at org.apache.tomcat.util.http.
ValuesEnumerator.nextElement(MimeHeaders.java:525)
[tomcat-coyote.jar:9.0.105]
at org.apache.tomcat.util.http.
ValuesEnumerator.nextElement(MimeHeaders.java:490)
[tomcat-coyote.jar:9.0.105]
at
org.apache.cxf.transport.http.HttpServletRequestSnapshot.getHeader(HttpServletRequestSnapshot.java:124)
[cxf-rt-transports-http-3.5.5.jar]
Now checking that specific line number in the source code...yields
something odd...
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/tomcat/util/http/MimeHeaders.java#L509
and it's @Override line...
so i dug a bit further and decompiled the jar in order to understand what's
going on here. (issue 3)
private void findNext() {
this.next=null;
for (; this.pos < this.size; this.pos++) {
MessageBytes n1 = this.headers.getName(this.pos); //fails here!
if (n1.equalsIgnoreCase(this.name)) {
this.next = this.headers.getValue(this.pos);
break;
}
}
this.pos++;
}
Apologies for the formatting as i had to retype this by hand. This would
seem to imply that there's an extra 9 lines or so of code in the jar i'm
using, which was from a docker public container tomcat:9.0-jdk11
Additional info: I did wireshark this and was able to see the message
before going to tomcat and it looks ok. Headers all appeared to be there
and were well formed, nothing out of the ordinary.
Questions/issue summary
(1) apparent inconsistent access to a specific http header in tomcat with
behind a proxy. Sometimes it's there, something it isn't.
(2) NPE being thrown when enumerating headers. Any idea why am i getting a
NPE in this case?
(3) should be concerned that the git repo's source line numbers do not
align with what the jar is reporting? Hoping this isn't some kind of supply
chain attack
Some theories I've cooked up on questions (1, 2)
Since it's a CXF JAXWS SOAP service with springboot servlet, i'm pretty
sure the only way to get http headers is via @Resource WebServiceContext
injection and then dig down to get the servlet request. I was always under
the impression that this should be thread safe, but if it isn't, it's
possible that the MimeHeaders class, at least according to the javadocs may
have recycled before i got it to, thus making the 'headers' variable be
cleared out.
Or it could be a bug in cxf (it is an older version but I'm stuck until we
can update JREs) or maybe a tomcat bug. I did note that someone reporting
this issue many years ago on stack overflow, specifically here:
https://stackoverflow.com/questions/37493552 but as i said, the request
looks ok and no different than any other setup.
The only other thing that might be a factor was that we recently renewed
the server certificate key pair. Seems unlikely though. Pretty sure I'm not
using the tomcat native libraries for anything related to TLS
Anyhow, a long one but hopefully someone will have an idea.
TIA
[ANN] Apache Tomcat 11.0.8 Available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 11.0.8. Apache Tomcat 11 is an open source software implementation of the Jakarta Servlet, Jakarta 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 available to aid this process. Apache Tomcat 11.0.8 is a milestone release of the 11.0.x branch and has been made to provide users with early access to the new features in Apache Tomcat 11.0.x so that they may provide feedback. The notable changes compared to 11.0.7 include: - Provide finer grained control of multi-part request processing via two new attributes on the Connector element. - Mark the JSP wrapper for reload after a failed compilation. - Update Tomcat Native to 2.0.9 including Windows binaries built with OpenSSL 3.5.0. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-11.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-11.cgi Migration guides from Apache Tomcat 9.0.x and 10.1.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: Certificates and keystores. I think I may have asked this before.
industry standard is to use pkcs12 keystores. You can create them with kse and are functionally the same. You just specify the type when you create the keystore config on the connector On Tue, Jun 10, 2025 at 11:51 AM James H. H. Lampert wrote: > On 6/10/25 6:33 AM, Christopher Schultz wrote: > > > A Java Keystore file is just a container for one or more keys and/or > > certificates. You should have no problem *using* the certificate and key. > > > > You may have to do some tricks to convert from one format into another, > > and/or to import those things into your keystore. > > > > What file type(s) are you being given? > > I don't actually know at this time. But since I posted the question, > I've been doing some experiments with Keystore Explorer, and I learned > how to go from a JKS to the separate key and certificate files that > Apache HTTPD expects, and back to a brand new JKS, and actually have > something Tomcat can use, so hopefully, I'll be able to talk the > customer through the process of setting up a keystore. > > Back when I first started using KSE, I still had to create the initial > keystore and keypair in keytool, or Tomcat wouldn't accept it (some sort > of password issue, as I recall); it would seem that KSE has since been > improved. > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Thanks, Brian Wolfe https://www.linkedin.com/in/brian-wolfe-3136425a/
Re: Certificates and keystores. I think I may have asked this before.
James, On 6/9/25 11:53 AM, James H. H. Lampert wrote: Our customer Tomcat installations are, without exception, set up to use a Java Keystore file (mainly because that appeared to be the only option back when we started setting them up) I think this has come up before, but we have a customer wanting to use a wildcard cert that's most likely in a different form (I don't know exactly *what* form; the whole issue came up while I was on vacation). What's the best way to deal with this? A Java Keystore file is just a container for one or more keys and/or certificates. You should have no problem *using* the certificate and key. You may have to do some tricks to convert from one format into another, and/or to import those things into your keystore. What file type(s) are you being given? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Certificates and keystores. I think I may have asked this before.
On 6/10/25 6:33 AM, Christopher Schultz wrote: A Java Keystore file is just a container for one or more keys and/or certificates. You should have no problem *using* the certificate and key. You may have to do some tricks to convert from one format into another, and/or to import those things into your keystore. What file type(s) are you being given? I don't actually know at this time. But since I posted the question, I've been doing some experiments with Keystore Explorer, and I learned how to go from a JKS to the separate key and certificate files that Apache HTTPD expects, and back to a brand new JKS, and actually have something Tomcat can use, so hopefully, I'll be able to talk the customer through the process of setting up a keystore. Back when I first started using KSE, I still had to create the initial keystore and keypair in keytool, or Tomcat wouldn't accept it (some sort of password issue, as I recall); it would seem that KSE has since been improved. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
