[ANN] Apache Tomcat 9.0.104 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 9.0.104. 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.104 is a bugfix and feature release. The notable changes compared to 9.0.102 include: - Remove the requirement that an MD5 implementation must be provided by JRE. - Improve the handling of %nn URL encoding in the RewriteValve. - Various improvements to the JsonErrorReportValve. - Simplify build process by requiring Java 22 or newer for the release package. 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
10.1.x [ANN] are missing for x >= 33
I noticed this in February and have attempted multiple times to contact the list owners and have received no response. There are no posts for Tomcat 10.1.x to tomcat-announce after 33 on 2024-11-11. https://lists.apache.org/thread/pbovsrrm11jqwccwfj8c8655oy8vj1rx I rely on the tomcat-announce list for internal packaging and releases. Can this be looked at, please? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: HOWTO: the right way to configure security constraints to protect CGI scripts in web.xml
Mark, On 4/8/25 5:40 PM, Mark Thomas wrote: 8 Apr 2025 21:45:50 Christopher Schultz : Justin, On 4/8/25 3:16 AM, Justin Chen wrote: Dear users and supporters, Currently I have two CGI scripts: 1. "/cgi-bin/update" //an administrative command, required role="admin" 2. "/cgi-bin/updateOrder" //update order, required role="biz" In order to protect above endpoints via web.xml security-constraints mechanism, how shall I do? It should be as simple as this in your web.xml: Whether the below is correct depends on how the CGI Servlet is mapped. And the OP hasn't provided that information. +1 I first wrote, then deleted three paragraphs on that exact topic before sending my reply. I didn't want to go into too much detail because it really depends upon the use case. The best thing to do is declare exactly one CGI script per url-pattern, then match all security constraints matching each of those url-patterns. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 9.0.102 sessions
Thanks for the curl check. This is what I get from the default page (from the server) curl -vv http://www.myapp.co.uk/ * Trying 127.0.0.1... * TCP_NODELAY set * Connected to www.myapp.co.uk (127.0.0.1) port 80 (#0) > GET / HTTP/1.1 > Host: www.myapp.co.uk > User-Agent: curl/7.61.1 > Accept: */* > < HTTP/1.1 302 302 < Date: Wed, 09 Apr 2025 18:30:24 GMT < Server: Apache < Location: /main/ < Content-Length: 0 < Content-Type: text/html;charset=UTF-8 < * Connection #0 to host www.myapp.co.uk left intact I can use this now to narrow down which pages from the logs are creating the sessions. I will also look at your suggestions on the valve and session time out. Many thanks. On 09/04/2025 19:29, Christopher Schultz wrote: Greg, On 4/9/25 7:22 AM, Greg Huber wrote: I have noticed that seems I have alot of sessions open, when looking in the application manager. It was was 800+. I don't remember seeing it this high before. If I refresh the screen I can see the number going up slowly. I have not made any changes on my app that would cause this. I have reset it 10 minutes ago, and its now at 350. Does this sound OK? Maybe? What happens when you hit the root of your web application? Do you have any component that creates a session? You can probably check easily like this: $ curl -vv https://yoursite/yourapp/ If the response includes a Set-Cookie: JSESSIONID=... header than anybody coming by your application will create a session. If you use the default 30-minute session inactivity timeout, that means any casual passer-by, web crawler, or potential attacker can create as many sessions as they want. You might want to look at using the crawler session manager valve[1]. You may also want to reduce the default inactivity timeout for your sessions from 30 minutes to something shorter, then raise the timeout for each session after authentication. That way, these trivial sessions will time out more quickly. -chris [1] https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Crawler_Session_Manager_Valve - 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
Apache Tomcat 9 SAML Setup With Active Directory
Hi, Is there any current up-to-date documentation on how to setup Apache Tomcat 9 with SAML and Active Directory that is not AI generated? I know you can do Keycloak IdP with Tomcat, but I was trying to avoid setting up an identity provider. I am finding links, but I think there is some missing information on how-to. Regards, William Crowell This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.
Your connection is not private Issue
Hi, I'm experiencing an issue when accessing the production web servers without using the .xxx.com domain. The browser displays a message stating, "Your connection is not private." This problem occurs in Edge, Chrome, and Firefox, while the development environment URLs work well with or without domain names. I have verified that the SSL certificate is properly configured with the correct subject alternative names. Any guidance or suggestions on how to resolve this would be greatly appreciated. Tomcat Apache Version 10.1.39 is running on Microsoft Windows Server 2022 Standard. The application server is running on the Windows cluster: tps_app2 and tps_app3. The database server is running on the SQL Server cluster. Below is the list of URLs and Browsers on which they are running fine without any message. URLs Development: Chrome Firefox Edge https://tpsdashboard-dev..com/tpsDashboard/ Working Fine Working Fine Working Fine https://tps_app-dev2..com/tpsDashboard/ Working Fine Working Fine Working Fine https://tpsdashboard-dev/tpsDashboard/ Working Fine Working Fine Working Fine https://tps_app-dev2/tpsDashboard/ Working Fine Working Fine Working Fine URLs Production: https://tpsdashboard..com/tpsDashboard/ Working Fine Working Fine Working Fine https://tpsdashboardha..com/tpsDashboard/ Working Fine Working Fine Working Fine https://tps_app2..com/tpsDashboard/ Working Fine Working Fine Working Fine https://tps_app3..com/tpsDashboard/ Working Fine Working Fine Working Fine https://tpsdashboard/tpsDashboard/ Not Working Not Working Not Working https://tpsdashboardha/tpsDashboard/ Not Working Not Working Not Working https://tps_app2/tpsDashboard/ Working Fine Working Fine Working Fine https://tps_app3/tpsDashboard/ Working Fine Working Fine Working Fine Thank you!
Re: HOWTO: the right way to configure security constraints to protect CGI scripts in web.xml
Hi,
Per jsp-url per servlet is never on the menu.
The difference between CGI Servlet and JSP Servlet is the script file search
mechanism. e.g. two requests, "/xxx/update" and "/xxx/update/abc" are mapping
into two different JSP script files if ruled by JSP Servlet. Unfortunately,
the different requests are mapping to the same CGI script file if ruled by CGI
Servlet and /xxx/update lookup succeeded.
For those cgi part, suggest enhance url-pattern ("/cgi-bin/update" +
"/cgi-bin/update/*") for each specific security-constraint, e.g.:
```xml
admin-stuff
/cgi-bin/update
/cgi-bin/update/*
admin
```
Full web.xml for reference:
http://www.w3.org/2001/XMLSchema-instance";
xmlns="https://jakarta.ee/xml/ns/jakartaee";
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee
https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd";
id="WebApp_ID" version="6.0">
sec-lab
cgi
org.apache.catalina.servlets.CGIServlet
cgiPathPrefix
/WEB-INF/cgi
executable
C:\Perl\strawberry\perl\bin\perl.exe
5
cgi
/cgi-bin/*
CGI-protected-area
/cgi-bin/*
staff
admin-stuff
/cgi-bin/update
/cgi-bin/update/*
admin
biz-stuff
/cgi-bin/updateOrder
/cgi-bin/updateOrder/*
biz
BASIC
SecurityLab
The role is required to access cgi scripts
staff
The role is required to access administrative cgi
scripts
admin
The role is required to access biz purpose cgi
scripts
biz
Chenjp
From: Christopher Schultz
Sent: Thursday, April 10, 2025 2:22
To: users@tomcat.apache.org
Subject: Re: HOWTO: the right way to configure security constraints to protect
CGI scripts in web.xml
Mark,
On 4/8/25 5:40 PM, Mark Thomas wrote:
> 8 Apr 2025 21:45:50 Christopher Schultz :
>
>> Justin,
>>
>> On 4/8/25 3:16 AM, Justin Chen wrote:
>>> Dear users and supporters,
>>> Currently I have two CGI scripts:
>>> 1. "/cgi-bin/update" //an administrative command, required role="admin"
>>> 2. "/cgi-bin/updateOrder" //update order, required role="biz"
>>> In order to protect above endpoints via web.xml security-constraints
>>> mechanism, how shall I do?
>>
>> It should be as simple as this in your web.xml:
>
> Whether the below is correct depends on how the CGI Servlet is mapped.
> And the OP hasn't provided that information.
+1
I first wrote, then deleted three paragraphs on that exact topic before
sending my reply. I didn't want to go into too much detail because it
really depends upon the use case.
The best thing to do is declare exactly one CGI script per url-pattern,
then match all security constraints matching each of those url-patterns.
-chris
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 9.0.102 sessions
Greg, On 4/9/25 7:22 AM, Greg Huber wrote: I have noticed that seems I have alot of sessions open, when looking in the application manager. It was was 800+. I don't remember seeing it this high before. If I refresh the screen I can see the number going up slowly. I have not made any changes on my app that would cause this. I have reset it 10 minutes ago, and its now at 350. Does this sound OK? Maybe? What happens when you hit the root of your web application? Do you have any component that creates a session? You can probably check easily like this: $ curl -vv https://yoursite/yourapp/ If the response includes a Set-Cookie: JSESSIONID=... header than anybody coming by your application will create a session. If you use the default 30-minute session inactivity timeout, that means any casual passer-by, web crawler, or potential attacker can create as many sessions as they want. You might want to look at using the crawler session manager valve[1]. You may also want to reduce the default inactivity timeout for your sessions from 30 minutes to something shorter, then raise the timeout for each session after authentication. That way, these trivial sessions will time out more quickly. -chris [1] https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Crawler_Session_Manager_Valve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 9.0.102 sessions
Thanks for the reply. I have rechecked the manager app and the sessions are around 40, and steady. I did not notice the link on the number of sessions, and checking now I can see they are all under 30 minutes, which is good. I will go through the logs and analyse the urls to see what was triggering the session creation, normal web crawling should not. Cheers Greg On 09/04/2025 12:53, Mark Thomas wrote: On 09/04/2025 12:22, Greg Huber wrote: Hello, I have noticed that seems I have alot of sessions open, when looking in the application manager. It was was 800+. I don't remember seeing it this high before. Before what? If I refresh the screen I can see the number going up slowly. I have not made any changes on my app that would cause this. I have reset it 10 minutes ago, and its now at 350. You can use the Manager app to look at how long a session has been inactive. Are any of those beyond the session expiration time and not being cleaned up? Does this sound OK? It depends. 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: Monitoring Virtual Threads via JMX / MBeans in Tomcat
Hi Mark, I hope this message finds you well. I just wanted to send a quick reminder regarding the email I sent on 3rd April,2025 about Monitoring Virtual Threads via JMX / MBeans in Tomcat . If you haven’t had the chance to review it yet, I would greatly appreciate your thoughts or any updates at your earliest convenience. Thanks, Rose Mary From: Rose Mary P T Date: Thursday, 3 April 2025 at 5:37 PM To: Tomcat Users List , ma...@apache.org Subject: [EXTERNAL] RE: Monitoring Virtual Threads via JMX / MBeans in Tomcat HI Mark, Thanks for your response. I would like to seek your guidance regarding an issue I am encountering with my current Tomcat setup. Specifically, your recent suggestions appear to contradict my existing configuration. Could you kindly confirm HI Mark, Thanks for your response. I would like to seek your guidance regarding an issue I am encountering with my current Tomcat setup. Specifically, your recent suggestions appear to contradict my existing configuration. Could you kindly confirm whether the following executor and connector setup in Tomcat 10.1.36 is correct? In my setup, I am using Http11NioProtocol exclusively. However, I am noticing the following: * keepAliveCount remains zero. * connectionCount is consistently reported as 1. * There is no visible value for RequestProcessor#workerThreadName. Please see the screenshot : * [cid:image001.png@01DBA4BE.812049C0] I would greatly appreciate your insight into this matter, especially if the configuration provided requires any adjustments or if there are specific conditions I need to be aware of for the virtual threads to function as expected. To clarify your previous question on the deployed application in tomcat : This is a simple spring boot application which prints current date in a loop of 100 Thank you for your time and assistance. I look forward to your response. Regards, Rose Mary From: Mark Thomas Date: Thursday, 3 April 2025 at 2:49 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Monitoring Virtual Threads via JMX / MBeans in Tomcat On 28/03/2025 09:08, Rose Mary P T wrote: > Hi Mark, > Thank you for the confirmation. > As per your suggestion, I have modified the deployed application so that it > no longer spawns any threads but instead executes a few calls. Please clarify what you mean by "executes a few calls". > Additionally, I kept the previous executor and connection configurations for > Tomcat. However, I still do not see any noticeable changes in the > keepAliveCount attribute. The connectionCount currently shows a value of 1. > At this point, I'm unsure of the next troubleshooting steps or what specific > aspects to investigate further. Any guidance on what to focus on next would > be greatly appreciated. > Additionally, could you suggest if there is any MBean attribute that can help > identify whether the threads being used are virtual threads or platform > threads? For Tomcat requests, the current thread name includes "virt" if it is a virtual thread. Look at RequestProcessor#workerThreadName for one place to see the thread names used for requests With NIO2, keepAliveCount will always be -1 as it isn't tracked. Switching to NIO would make keepAliveCount available. connectionCount will always be 1 more than the current connections. i.e. a value of 1 means there are no current requests. Mark > Thank you for your continued support. > > Best Regards, > Rose Mary > > > From: Mark Thomas > Date: Thursday, 27 March 2025 at 9:25 PM > To: users@tomcat.apache.org > Subject: [EXTERNAL] Re: Monitoring Virtual Threads via JMX / MBeans in Tomcat > On 26/03/2025 10:38, Rose Mary P T wrote: >> Dear Tomcat Users, >> I hope this message finds you well. >> As per your previous email, we attempted to fetch the virtual thread count >> from the keepAliveCount attribute in the Catalina.ThreadPool MBean. >> For context, here is the setup we used: >> >> * We created a sample Spring Boot application that continuously >> creates virtual threads in a loop. > > If the application is creating the threads then this won't work. The > (connectionCount - keepAliveCount) approach only works for virtual > threads created by Tomcat for processing requests. > > If the application is creating the virtual threads then I'd suggest > adding tracking for the current number of virtual threads to the > application. > > Mark > >> * The application was deployed in the TOMCAT_LOCATION/webapps >> directory and started on localhost. >> In Apache Tomcat 10.1.36, we added the following configuration to the >> server.xml file to enable virtual threads: >> > className="org.apache.catalina.core.StandardVirtualThreadExecutor"/> >> > connectionTimeout="18000" redirectPort="8443" >> executor="tomcatExecutor" >> useVirtualThreads="true"/> >> >> Its observed in the logs that virtual threads were being created as >> expected. However, we notic
Re: Monitoring Virtual Threads via JMX / MBeans in Tomcat
On 03/04/2025 13:05, Rose Mary P T wrote: HI Mark, Thanks for your response. I would like to seek your guidance regarding an issue I am encountering with my current Tomcat setup. Specifically, your recent suggestions appear to contradict my existing configuration. Could you kindly confirm whether the following executor and connector setup in Tomcat 10.1.36 is correct? className="org.apache.catalina.core.StandardVirtualThreadExecutor"/> That should work. Although I do wonder on why you have configured an executor here. There isn't really any point with virtual threads. In my setup, I am using *Http11NioProtocol* exclusively. However, I am noticing the following: * *keepAliveCount* remains zero. * *connectionCount* is consistently reported as 1. That suggests that the Tomcat instance isn't processing any requests. * There is no visible value for |RequestProcessor#workerThreadName|. Please see the screenshot : Screenshots don't work on the mailing list. Post it somewhere we can look at it. Mark * I would greatly appreciate your insight into this matter, especially if the configuration provided requires any adjustments or if there are specific conditions I need to be aware of for the virtual threads to function as expected. To clarify your previous question on the deployed application in tomcat : This is a simple spring boot application which prints current date in a loop of 100 Thank you for your time and assistance. I look forward to your response. Regards, Rose Mary *From: *Mark Thomas *Date: *Thursday, 3 April 2025 at 2:49 PM *To: *users@tomcat.apache.org *Subject: *[EXTERNAL] Re: Monitoring Virtual Threads via JMX / MBeans in Tomcat On 28/03/2025 09:08, Rose Mary P T wrote: Hi Mark, Thank you for the confirmation. As per your suggestion, I have modified the deployed application so that it no longer spawns any threads but instead executes a few calls. Please clarify what you mean by "executes a few calls". Additionally, I kept the previous executor and connection configurations for Tomcat. However, I still do not see any noticeable changes in the keepAliveCount attribute. The connectionCount currently shows a value of 1. At this point, I'm unsure of the next troubleshooting steps or what specific aspects to investigate further. Any guidance on what to focus on next would be greatly appreciated. Additionally, could you suggest if there is any MBean attribute that can help identify whether the threads being used are virtual threads or platform threads? For Tomcat requests, the current thread name includes "virt" if it is a virtual thread. Look at RequestProcessor#workerThreadName for one place to see the thread names used for requests With NIO2, keepAliveCount will always be -1 as it isn't tracked. Switching to NIO would make keepAliveCount available. connectionCount will always be 1 more than the current connections. i.e. a value of 1 means there are no current requests. Mark Thank you for your continued support. Best Regards, Rose Mary From: Mark Thomas Date: Thursday, 27 March 2025 at 9:25 PM To: users@tomcat.apache.org Subject: [EXTERNAL] Re: Monitoring Virtual Threads via JMX / MBeans in Tomcat On 26/03/2025 10:38, Rose Mary P T wrote: Dear Tomcat Users, I hope this message finds you well. As per your previous email, we attempted to fetch the virtual thread count from the keepAliveCount attribute in the Catalina.ThreadPool MBean. For context, here is the setup we used: * We created a sample Spring Boot application that continuously creates virtual threads in a loop. If the application is creating the threads then this won't work. The (connectionCount - keepAliveCount) approach only works for virtual threads created by Tomcat for processing requests. If the application is creating the virtual threads then I'd suggest adding tracking for the current number of virtual threads to the application. Mark * The application was deployed in the TOMCAT_LOCATION/webapps directory and started on localhost. In Apache Tomcat 10.1.36, we added the following configuration to the server.xml file to enable virtual threads: Its observed in the logs that virtual threads were being created as expected. However, we noticed that the keepAliveCount attribute in the Catalina.ThreadPool MBean is showing a value of 0, even though virtual threads are being spawned. It seems that the keepAliveCount attribute does not provide a valid value for counting the virtual threads. We were wondering if this is expected behavior, or if there is a different way to monitor the virtual threads created in Tomcat. We would also like to know if there's a way to differentiate between platform threads and virtual threads using any MBean attribute in the Catalina service or elsewhere in Tomcat's MBean architecture. We would greatly appreciate any guidance or insights you can provide regarding this issue. Best Regards, Rose Mary
Re: EOL timeline for tomcat 9 and 10.1
On 08/04/2025 13:29, Aniket Pachpute wrote: No Plans. Please See: https://lists.apache.org/thread/qlzpscgoqct9wspkj5qjkm34s66jswj0 Plans have evolved a little since that message. For Tomcat 9: https://lists.apache.org/thread/o8d1nz8mj8dhwq88jbt7zxopp3omkkkb Work has now started on Tomcat 12 / Jakarta EE 12 and there does seem to be a desire within the Jakarta EE project for a faster release cadence. It remains to be seen how that translates into Tomcat releases but - as always - the community will be involved in - and have full visibility of - any discussions. Mark On Tue, 8 Apr 2025 at 2:05 PM, Vishwas Bm wrote: Hi, I was looking at the EOL page for tomcat https://endoflife.date/tomcat but couldn't get information related to EOL dates for tomcat 9 and 10.1. With tomcat11 available now, may I know till what date tomcat 9.0 and Tomcat 10.1 will be supported ? Is there any specific dates already planned for this ? Regards, Vishwas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Clustering Roadmap And Max Node Limit
On 08/04/2025 00:27, Tim N wrote: Thanks for clarifying that. Does BackupManager support auto-scaling Yes, if you use a cluster membership mechanism that allows that. and cycled restarts of all nodes (for web-app upgrades) without losing the user's session? Yes, but you need to trigger the restarts manually. There is no mechanism to automate that. If the backup node is restarted...the backup is lost isn't it? That isn't how the backup manager works. There isn't a single backup node. TL;DR backups for one node are distributed around the cluster. There are several presentations by me on the Tomcat website that discuss this. Maybe start with this one from slide 12. Slides: https://tomcat.apache.org/presentations/2013-02-acna-Apache-Tomcat-Clustering.pdf Video: https://www.youtube.com/watch?v=rX1zm11AXcA HTH, Mark On Fri, Apr 4, 2025 at 8:23 PM Mark Thomas wrote: On 04/04/2025 02:42, Chuck Caldarale wrote: On 2025 Apr 3, at 19:57, Tim N wrote: For a long time up to the latest version 11 documentation, there has been a recommended maximum limit of 4 nodes per cluster. https://tomcat.apache.org/tomcat-11.0-doc/cluster-howto.html "This works great for smaller clusters, but we don't recommend it for larger clusters — more than 4 nodes or so." Are there any plans to improve this? It's a pity to have to change the architecture when going from, say, 3 notes to 8 by introducing farms. What is the next simplest free cluster to move to? Redis? Any idea how cluster farming compares with redis? What other options are there? I may be misreading the documentation, but I think the 4-node restriction applies to the DeltaManager, and using the BackupManager removes the limitation. Chuck is correct. The issue with the DeltaManager is that the cluster traffic scales with the square of the number of nodes. For the BackupManager traffic scales linearly with the number of nodes. The limit of 4 is one of those values that should work with most applications. Depending on your application, the actual limit may be higher. Mark - Chuck - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
9.0.102 sessions
Hello, I have noticed that seems I have alot of sessions open, when looking in the application manager. It was was 800+. I don't remember seeing it this high before. If I refresh the screen I can see the number going up slowly. I have not made any changes on my app that would cause this. I have reset it 10 minutes ago, and its now at 350. Does this sound OK? Cheers Greg
Exception: Server name value of host_name cannot have the trailing dot
Hi,
I am getting below error when having tomcat server name with trailing dot
(.) when using tomcat 10.
>From the stacktrace, it looks like it is coming as part of SNI handling.
Is this supported in tomcat 11 or any way to bypass it ?
javax.net.ssl.SSLProtocolException: Illegal server name, type=host_name(0),
name=tomcat-login.osns.svc.cluster.local., value={.}
at
java.base/sun.security.ssl.ServerNameExtension$CHServerNamesSpec.(Unknown
Source)
at
java.base/sun.security.ssl.ServerNameExtension$CHServerNamesStringizer.toString(Unknown
Source)
at java.base/sun.security.ssl.SSLExtension.toString(Unknown Source)
at java.base/sun.security.ssl.SSLExtensions.toString(Unknown Source)
at
java.base/sun.security.ssl.ClientHello$ClientHelloMessage.toString(Unknown
Source)
at
java.base/sun.security.ssl.SSLLogger$SSLSimpleFormatter.formatObject(Unknown
Source)
at
java.base/sun.security.ssl.SSLLogger$SSLSimpleFormatter.formatParameters(Unknown
Source)
at java.base/sun.security.ssl.SSLLogger.log(Unknown Source)
at java.base/sun.security.ssl.SSLLogger.fine(Unknown Source)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
Source)
at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown
Source)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source)
at java.base/java.security.AccessController.doPrivileged(Unknown
Source)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown Source)
at
org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:429)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:494)
at
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:215)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1769)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
at java.base/java.lang.Thread.run(Unknown Source)
* Caused by: java.lang.IllegalArgumentException: Server name value of
host_name cannot have the trailing dot*
at java.base/javax.net.ssl.SNIHostName.checkHostName(Unknown Source)
at java.base/javax.net.ssl.SNIHostName.(Unknown Source)
... 25 more}
*Thanks & Regards,*
*Vishwas *
Re: 9.0.102 sessions
On 09/04/2025 12:22, Greg Huber wrote: Hello, I have noticed that seems I have alot of sessions open, when looking in the application manager. It was was 800+. I don't remember seeing it this high before. Before what? If I refresh the screen I can see the number going up slowly. I have not made any changes on my app that would cause this. I have reset it 10 minutes ago, and its now at 350. You can use the Manager app to look at how long a session has been inactive. Are any of those beyond the session expiration time and not being cleaned up? Does this sound OK? It depends. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Exception: Server name value of host_name cannot have the trailing dot
On 09/04/2025 12:45, Vishwas Bm wrote:
Hi,
I am getting below error when having tomcat server name with trailing dot
(.) when using tomcat 10.
From the stacktrace, it looks like it is coming as part of SNI handling.
That is generated by the JRE. Nothing to do with Tomcat.
I'll note that RFC 6066 states that the trailing dot should not be
present so this JRE exception looks to be correct.
Mark
Is this supported in tomcat 11 or any way to bypass it ?
javax.net.ssl.SSLProtocolException: Illegal server name, type=host_name(0),
name=tomcat-login.osns.svc.cluster.local., value={.}
at
java.base/sun.security.ssl.ServerNameExtension$CHServerNamesSpec.(Unknown
Source)
at
java.base/sun.security.ssl.ServerNameExtension$CHServerNamesStringizer.toString(Unknown
Source)
at java.base/sun.security.ssl.SSLExtension.toString(Unknown Source)
at java.base/sun.security.ssl.SSLExtensions.toString(Unknown Source)
at
java.base/sun.security.ssl.ClientHello$ClientHelloMessage.toString(Unknown
Source)
at
java.base/sun.security.ssl.SSLLogger$SSLSimpleFormatter.formatObject(Unknown
Source)
at
java.base/sun.security.ssl.SSLLogger$SSLSimpleFormatter.formatParameters(Unknown
Source)
at java.base/sun.security.ssl.SSLLogger.log(Unknown Source)
at java.base/sun.security.ssl.SSLLogger.fine(Unknown Source)
at
java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(Unknown
Source)
at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown
Source)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(Unknown
Source)
at java.base/java.security.AccessController.doPrivileged(Unknown
Source)
at
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(Unknown Source)
at
org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:429)
at
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:494)
at
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:215)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1769)
at
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
at java.base/java.lang.Thread.run(Unknown Source)
* Caused by: java.lang.IllegalArgumentException: Server name value of
host_name cannot have the trailing dot*
at java.base/javax.net.ssl.SNIHostName.checkHostName(Unknown Source)
at java.base/javax.net.ssl.SNIHostName.(Unknown Source)
... 25 more}
*Thanks & Regards,*
*Vishwas *
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
