Re: remote address is localhost after upgrading tomcat instance behind reverse proxy from tomcat8.5 to tomcat9

[Mark Thomas]

On 06/11/2024 21:17, Ivano Luberti wrote:
Hi, as stated in the subject, we had a correctly behaving tomcat 8.5 
behind a reverse proxy implemented with Apache.


After upgrading to Tomcat 9  every request is seen by tomcat as coming 
from localhost.


Apache and Tomcat are running on the same machine and reverse proxy is 
implemented forwarding the request to localhost.


To say it all, before the upgrade requests arrived to tomcat via ip v4 
and after upgrade via ip v6


I have seen in the doc that there is a filter in tomcat to deal with 
this, but I would like to know why it was working with tomcat 8.5 and 
not with tomcat 9 and if there is a solution properly configuring Apache 
without touching Tomcat


If you upgraded Tomcat and are seeing changes in behaviour then doesn't 
that suggest Tomcat, rather than httpd, is where you need to make changes?


We'll need more information to provide useful advice including:

- which protocol are you using to reverse proxy from httpd to Tomcat

- httpd configuration for the reverse proxy

- Tomcat Connector configuration for whichever port(s) httpd is passing
  requests to

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 10.1 STIGing

[Mark Thomas]

On 28/10/2024 21:44, Leroy Mims wrote:

My place of work prefers DISA STIGed software. I contacted DISA about STIGs
for Tomcat 10.1 and they said that the organization that produces the
software has to request that it be STIGed. The idea of applyingTomcat 9
STIGs to Tomcat 10.1 was rejected and DISA STIGs are preferable to CIS
Benchmarks.
Thank you.
Leroy Mims


I am not aware of any plans for the Tomcat team to request a STIG 
assessment for Tomcat 10. Should such a proposal be made, I would argue 
strongly NOT to make such a request.


My personal recommendation is to avoid the STIG recommendations at all 
costs. The last time I reviewed the latest STIG for Tomcat it contained 
a large amount of utter nonsense. I've just looked up the latest 
recommendations (2024-05-23) for Tomcat 9 and it still contains this howler:


https://www.stigviewer.com/stig/apache_tomcat_application_server_9/2024-05-23/finding/V-222950

That such a finding was written, reviewed and approved gives me zero 
confidence in the entire STIG process.


We started a community review of the previous Tomcat 9 STIG:

https://cwiki.apache.org/confluence/display/TOMCAT/Community+Review+of+DISA+STIG

I lost interest after the first half-dozen or so issues due to the sheer 
volume of problems I was finding and that no-one else seemed interested 
in either contributing or in the results.


The CIS benchmarks appear to be of better quality but they still contain 
some issues such as not fully accounting for the correct secure 
connector settings when running Tomcat behind a reverse proxy.


I did reach out to the CIS benchmark folks to point out some of the 
errors I found but their response was rather disappointing. It was - 
essentially - join our review team and provide all the corrections for 
free (so we can then sell benchmark to commercial customers).


I don't mind contributing to community resources - I wouldn't be 
contributing to open source if I did - but I do object to being asked to 
provide my time at zero cost to support someone else's commercial product.


What I do recommend is start with the security how-to in the Tomcat docs 
and then ask any questions you have here.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Mark Thomas]

On 11/10/2024 01:05, Eric Robinson wrote:

Mark,

Thanks very much for the update. We'll check back in November!


I've just committed the fix. It should be in the next set of releases 
(November).


Mark




-Eric


-Original Message-
From: Mark Thomas 
Sent: Thursday, October 10, 2024 5:30 PM
To: users@tomcat.apache.org
Subject: Re: Database Connection Requests Initiated but Not Sent on the Wire 
(Some, Not All)

Eric,

My apologies. I dropped the ball on this one. I've just re-read the thread to 
remind myself of the details. I'm aiming to get this fixed for the November 
release round.

Mark


On 10/10/2024 10:10, Eric Robinson wrote:

Hi Mark,

Just following up on this. Did you arrive at the long-term solution? This issue 
is still biting us.


-Original Message-
From: Eric Robinson 
Sent: Thursday, May 30, 2024 4:15 PM
To: Tomcat Users List 
Subject: RE: Database Connection Requests Initiated but Not Sent on
the Wire (Some, Not All)

Hi Mark,


-Original Message-----
From: Mark Thomas 
Sent: Thursday, May 30, 2024 9:30 AM
To: users@tomcat.apache.org
Subject: Re: Database Connection Requests Initiated but Not Sent on
the Wire (Some, Not All)

OK.

This is an interim binary patch for 9.0.80 only.

The purpose is to:
- confirm the proposed change fixes the problem
- provide you with a workaround in the short term

This is the binary patch:

https://people.apache.org/~markt/dev/classloader-not-found-cache-9.0.
8
0-
v1.zip

Extract the contents into $CATALINA_HOME/lib

You should end up with:

$CATALINA_HOME/lib/org/apache/...



I'll get on this right away.


Usual caveats apply. This is not an official release. Use it at your
own risk. Don't blame either me or the ASF it is results in alien
invasion, a tax bill, the server catching fire or anything else unexpected 
and/or unwanted.



Okay, but if we're invaded by alien tax collectors riding flaming servers, THEN 
I'm coming after you.


Longer term, I'm not sure this is exactly how I want to fix it in
Tomcat. I am convinced of the need to cache classes that don't exist
but exactly where / how to do that and what degree of control the user should 
have is very much TBD.

I suspect this will be a topic of discussion at Community Over Code
at Bratislava next week.

I am expecting that any fix won't be in the June release round but
should be in the July release round.

Let us know how you get on and good luck.



Will do!



Mark


On 30/05/2024 10:16, Mark Thomas wrote:

On 29/05/2024 17:03, Eric Robinson wrote:




One of the webapps is related to voice reminder messages that go
out to people. The reminders go out sometime after 9 am, which
tracks with the slowdowns.


Ack.

Something to try while I work on a patch is setting
archiveIndexStrategy="bloom" on the resources.

You'd configure that in META-INF/context.xml something like this:


  

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


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.
Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
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

Disclaimer : This email and any files transmitted

Re: Fwd: NoClassDefFoundError: javax/mail/Authenticator

[Mark Thomas]

On 24/10/2024 17:07, Alan Masters wrote:
I am attempting to send e-mail from Tomcat using an external mail host - 
   mail.btinternet.com.


I have included javax.mail jar in my build path and can see 
javax.mail.Authenticator in this library.


When trying to start up  apache-tomcat-9.0.91 I get 
IllegalStateException: Error starting child


    Caused by: java.lang.NoClassDefFoundError: javax/mail/Authenticator

any help would be appreciated please.


Could we see the full stack trace?

Have you included it in your web application? If so, where?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: javax.naming.NameNotFoundException

[Mark Thomas]

On 23/10/2024 23:13, Mark Foley wrote:

On Wed, 23 Oct 2024 19:13:44 Mark Thomas  wrote:





That won't work. What will work is renaming:

$CATALINA_HOME/webapps/myapp

to

$CATALINA_HOME/webapps/myapp#subapp/

Mark


Hmmm ... what I was attempting was splitting many webapps into multiple
directories. I have a top-level organization which would be like:

$CATALINA_HOME/webapps/GrandWaterBuffalo/

Then subordinate to that would be sub-orgs like:

$CATALINA_HOME/webapps/GrandWaterBuffalo/districtA
$CATALINA_HOME/webapps/GrandWaterBuffalo/districtB
$CATALINA_HOME/webapps/GrandWaterBuffalo/districtC

etc. Perhaps 30+ at this level. Then sub-orgs for each of these like:

$CATALINA_HOME/webapps/GrandWaterBuffalo/districtA/Chapter1
$CATALINA_HOME/webapps/GrandWaterBuffalo/districtA/Chapter2
$CATALINA_HOME/webapps/GrandWaterBuffalo/districtA/Chapter3

etc.  Probably around 10-ish "Chapters" per District.  As you can see, this
could result in many webapps.  I was trying not to put them all under one
$CATALINA_HOME/webapps/ directory level, but your example effectively does that.

So, no way around this?


You can move the webapps all out of $CATALINA_HOME/webapps but then 
you'll still have 100s of context.xml files in 
$CATALINA_HOME/catalina/localhost or (worse) 100s of  
entries in server.xml to reference the external locations.



What do hosting sites do that may have several hundred
webapps for different customers?


I don't know. I suspect a lot have moved to 1 container per customer. 
Which may just move the problem.



Just put everything under $CATALINA_HOME/webapps?


With a sensible naming convention that is probably the approach I'd take.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: javax.naming.NameNotFoundException

[Mark Thomas]

On 23/10/2024 18:57, Mark Foley wrote:

I'm running Tomcat 8.5.11. I have a hopefully small problem.


Tomcat 8.5.x is EOL and no longer supported.

8.5.11 is also rather old with quite a long list of know security issues.


I have a webapp directory: $CATALINA_HOME/webapps/myapp/. In that directory I 
have WEB-INF/web.xml with:


   connURL
   jdbc:mysql://localhost/members?
   java.lang.String


In this example, the env-entry is just part of an SQL connection string I want 
to snag.

In a browser, going to: /myapp/index.jsp works fine with WEB-INF as shown 
above.

What I want to do is put all of this in a sub-directory: 
$CATALINA_HOME/webapps/myapp/subapp/ and access it on my browser as 
/myapp/subapp/index.jsp. When I do that -- no changes to anything -- I 
get the error:


That won't work. What will work is renaming:

$CATALINA_HOME/webapps/myapp

to

$CATALINA_HOME/webapps/myapp#subapp/

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomca 9.96 und semeru

[Mark Thomas]

On 20/10/2024 15:45, Andreas Moroder wrote:

Hello Mark,

I made some more test, but it works only for a few clicks, then the
service stops. It's running on windows ( for reasons I dont'know and
can't change)

with semeru 17 I see this lines in the logs


I see a couple of problems with that code:


18-Oct-2024 15:04:41.484 SEVERE [main]
org.apache.catalina.core.StandardContext.startInternal One or more
Filters failed to start. Full details will be found in the appropriate
container log file
18-Oct-2024 15:04:41.484 SEVERE [main]
org.apache.catalina.core.StandardContext.startInternal Context
[/balancer] startup failed due to previous errors



18-Oct-2024 15:04:41.484 SEVERE [main]
org.apache.catalina.core.StandardContext.filterStart Exception starting
filter [BalancerFilter]
java.lang.NoSuchMethodError:
org/apache/tomcat/util/digester/Digester.addObjectCreate(Ljava/lang/ 
String;Ljava/lang/Class;)V(loaded

from file:/C:/Tomcat/9_0_96/lib/tomcat-util-scan.jar by
java.net.URLClassLoader@634de460) called from class
org.apache.webapp.balancer.RulesParser (loaded from
file:/C:/Tomcat/9_0_96/webapps/balancer/WEB-INF/lib/catalina-balancer.jarby
ParallelWebappClassLoader
   context: balancer
   delegate: false
--> Parent Classloader:
java.net.URLClassLoader@634de460
).


Web application code should not be calling Tomcat's internal API. Tomcat 
makes no guarantees about the stability of the internal API between 
point releases.


There is no o.a.t.u.digesterDigester.addObjectCreate(String,Class) 
method so the exception is correct. The method was present in Tomcat 7 
but it was removed over a decade ago (Feb 2013) as part of a general 
cleanup the removed unused code between Tomcat 7 and Tomcat 8.5.


Why semeru triggers that code path is something only you can answer by 
looking at the application code.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 11 & Request Attributes

[Mark Thomas]

On 20/10/2024 02:49, Dan McLaughlin wrote:

We use Shibboleth SP, which passes request attributes from Apache over AJP
to Tomcat; after upgrading from Tomcat 10.1 to Tomcat 11, the request
attributes aren't coming over.  Does anyone know of anything that changed
in Tomcat 11 that might affect request attributes being passed over AJP?


Compare the AJP Connector configuration between 10.1 and 11.0. I suspect 
allowedRequestAttributesPattern is not set correctly for 11.0.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Assistance with Apache Tomcat Integration with MS Sentinel

[Mark Thomas]

On 18/10/2024 09:55, Kele Masemola wrote:

Good day,

We are trying to integrate Tomcat Apache with Sentinel, so we just wanted to 
get some clarity on a few things. We installed Apache Tomcat data connector on 
Sentinel. It seems the Apache servers in our environment are running on Windows 
machines, so when we download and install the windows agent on the Apache 
Tomcat servers, will the logs go through our syslog server via AMA or through 
our syslog server via CEF?


That would be a question for your MS Sentinel support channel.


It seems the version of Apache Tomcat currently being run in the environment is 
Apache Tomcat/9.0.85, is it compatible with the Deprecated Apache Tomcat data 
connector on MS Sentinel, which was developed using Apache Tomcat version 
10.0.4?


Another question for your MS Sentinel support channel.

Regards,

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Supportability of Tomcat 9.0.90 and above with JDK 8

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Joseph,

> -Ursprüngliche Nachricht-
> Von: Xavier, Joseph 
> Gesendet: Donnerstag, 17. Oktober 2024 10:59
> An: rainer.j...@kippdata.de
> Cc: Tomcat Users List 
> Betreff: RE: Supportability of Tomcat 9.0.90 and above with JDK 8
> 
> Hi Rainer,
> 
> Thank you for the info. We did look at this matrix but we also found a
> conflicting article as well:
> 
> https://tomcat.apache.org/tomcat-9.0-doc/building.html
> 
> In this, the required JDK version is said to be JDK 11 or above. Can you help 
> me
> understand the differences between the 2 articles?
> 
> Thank you
> Joseph X.
> 


The difference is building and running.
You need a certain JDK for building which might be different from the supported 
runtime environment.


> -Original Message-
> From: Rainer Jung 
> Sent: Thursday, October 17, 2024 1:54 PM
> To: Tomcat Users List 
> Subject: Re: Supportability of Tomcat 9.0.90 and above with JDK 8
> 
> Caution: This email originated from outside of the organization. Review for
> Phishing!
> 
> 
> Am 17.10.24 um 08:27 schrieb Xavier, Joseph:
> > Hi,
> >
> > I wanted to understand whether Tomcat 9.0.90 and above minor versions
> are supported with JDK 8? We have see compile issues when our JDK 8
> environment tried to work with Tomcat 9.0.90.
> > If the supportability is deprecated, is there any doc or public announcement
> stating the same?
> 
> Hi Joseph,
> 
> yes TC 9 is supported with JDK 8 (and higher), see
> 
> https://urldefense.com/v3/__https://tomcat.apache.org/whichversion.html_
> _;!!KpaPruflFCEp!ma-
> 2pPcVOuOsTkmfs7DESyaBow4GmIAfNqWr6x_pYE0_HUDDFMxTLosQB8Y-
> rtDMk7ZVj1BvF8CMlyuVg9x7e9BwtTlq$
> 
> Independent of your JDK 8 problems, you should try to stay current, so
> instead of 9.0.90 use 9.0.96 and define a patch strategy to let your 
> installation
> not diverge too much from 9.0.current.
> 
> Concerning your specific JDK 8 problem you can do a separate post to the list
> describing your observed problem.
> 
> Best regards,
> 
> Rainer
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat 9.0.96 and ibm semeru

[Mark Thomas]

15 Oct 2024 13:59:57 Andreas Moroder :


Hello,

we have Tomcat 9.0.96  and Java 8.
We would like to get rid of Oracle java and use IBM semeru.

Can Oracle java simply be replaced by ibm semeru,


Yes.


or are changes to the java and jsp applications necessary?


No.


Do the java libraries we call from our jsp-pages have to be recompiled?


No.

The only caveats to the above are:

If your application uses any non-public Java API (usually via reflection) 
there is a small risk it will break.


Likewise for the places where Tomcat does this (from memory just the 
memory leak protection and that can be disabled if it is an issue)


There is a small risk you find a JRE bug you didn't see with Oracle.

Overall, all of those risks are very small. I'd expect it to just work.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Mark Thomas]

Eric,

My apologies. I dropped the ball on this one. I've just re-read the 
thread to remind myself of the details. I'm aiming to get this fixed for 
the November release round.


Mark


On 10/10/2024 10:10, Eric Robinson wrote:

Hi Mark,

Just following up on this. Did you arrive at the long-term solution? This issue 
is still biting us.


-Original Message-
From: Eric Robinson 
Sent: Thursday, May 30, 2024 4:15 PM
To: Tomcat Users List 
Subject: RE: Database Connection Requests Initiated but Not Sent on the Wire 
(Some, Not All)

Hi Mark,


-Original Message-
From: Mark Thomas 
Sent: Thursday, May 30, 2024 9:30 AM
To: users@tomcat.apache.org
Subject: Re: Database Connection Requests Initiated but Not Sent on
the Wire (Some, Not All)

OK.

This is an interim binary patch for 9.0.80 only.

The purpose is to:
- confirm the proposed change fixes the problem
- provide you with a workaround in the short term

This is the binary patch:

https://people.apache.org/~markt/dev/classloader-not-found-cache-9.0.8
0-
v1.zip

Extract the contents into $CATALINA_HOME/lib

You should end up with:

$CATALINA_HOME/lib/org/apache/...



I'll get on this right away.


Usual caveats apply. This is not an official release. Use it at your
own risk. Don't blame either me or the ASF it is results in alien
invasion, a tax bill, the server catching fire or anything else unexpected 
and/or unwanted.



Okay, but if we're invaded by alien tax collectors riding flaming servers, THEN 
I'm coming after you.


Longer term, I'm not sure this is exactly how I want to fix it in
Tomcat. I am convinced of the need to cache classes that don't exist
but exactly where / how to do that and what degree of control the user should 
have is very much TBD.

I suspect this will be a topic of discussion at Community Over Code at
Bratislava next week.

I am expecting that any fix won't be in the June release round but
should be in the July release round.

Let us know how you get on and good luck.



Will do!



Mark


On 30/05/2024 10:16, Mark Thomas wrote:

On 29/05/2024 17:03, Eric Robinson wrote:




One of the webapps is related to voice reminder messages that go
out to people. The reminders go out sometime after 9 am, which
tracks with the slowdowns.


Ack.

Something to try while I work on a patch is setting
archiveIndexStrategy="bloom" on the resources.

You'd configure that in META-INF/context.xml something like this:


 

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


Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.
Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
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: SSL on Tomcat 9

[Mark Thomas]

On 09/10/2024 07:47, Ron Boyer wrote:

hello, I am trying to renew the SSL certificate from a signing authority.  I am 
running Tomcat 9.  I understand that I have to import PKCS #12 certificate.  I 
seem to be able to make one, but I don't think it is correct.  My signing 
authority, GoDaddy, will let me download a crt and pem file. From the 
server.xml file I see there is only one entry that points to the keystore of a 
PKCS #12 key.  I don't know  whether I need to import the certificate with 
keytool or using the certificate snap-in with Windows Management Console.  Any 
advice?


How did you create the private key (show us the command line if you can) 
and what format is the key in?


If you followed an on-line guide (e.g. from GoDaddy) can you provide a 
reference to that?


Why do you think what you are doing is incorrect?

What is your TLS connector configuration (show use the XML but mask any 
sensitive information like passwords)?


What do the logs show for that Connector when Tomcat starts?

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Migrating from Tomcat 9.0.88 to Tomcat 10.1.30 on windows machine with JDK 21 LTS

[Mark Thomas]

On 09/10/2024 05:49, Sajid Hussain wrote:

Hi,

Thanks for the quick response. Yes its spring boot application and 
packaged as War file. The Tomcat running as windows service using Apache 
common daemon.


I'm also attaching the stack trace observe in memory analyzer.


You need to look at the heap usage to see where the memory is being used.

Most profilers should also be able to tell where the CPU time is being 
spent.


Did you look at DAEMON-460? Does it apply to you?

Mark





Regards,
Sajid

On 10/9/2024 4:24 PM, Mark Thomas wrote:

Please send your reply to the users list so I can reply there.

Mark


On 08/10/2024 06:23, Sajid Hussain wrote:

Hi Mark,

Thanks for the quick response. Yes its spring boot application and 
packaged as War file. The Tomcat running as windows service using 
Apache common daemon.



Sajid

On 10/8/2024 4:47 PM, Mark Thomas wrote:

On 08/10/2024 05:21, Sajid Hussain wrote:

Hi,

I was using tomcat 9 with JDK 17 on windows. My java application 
was using 2.7.18. Now I'm migrating my application spring version 
to 3.3.4 with Tomcat 10.1.30 and JDK 21. I have upgraded the 
version in my java project and fix the hibernate error migrating 
from 5 to 6. Now my application start on tomcat 10. But after few 
request JVM consume the maximum memory (I set it 3GB max) and cup 
usage to 90-98%. I set windows service priority to low and it take 
80-90% hence my application stop responding. Here is the thread dum 
for the tomcat.Not getting any clue whats causing to tomcat high 
CPU and memory usage.


A profiler (I use YourKit because they give free licenses to OSS 
develoeprs but other profilers are avialable) will tell you more 
about what is going on than a single stack trace.


Is this a Spring Boot app? Is it packaged as a JAR or a WAR?

How are you running this as a Windows service? If you are using 
Apache Commons Daemon (the default way to run Tomcat as a Windows 
service) then this might be useful:

https://issues.apache.org/jira/projects/DAEMON/issues/DAEMON-460

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



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: net::ERR_HTTP2_PROTOCOL_ERROR with 10.1.30

[Mark Thomas]

On 09/10/2024 03:33, Boris Petrov wrote:
I also have been experiencing the same issue (with Tomcat 9). 9.0.93 
works fine. 9.0.94 is unusable. 9.0.95 and now 9.0.96 almost work but 
sometimes I get the same behavior as with 9.0.94. I see it in my 
integration tests - there are some sporadic failures here and there when 
I upgrade from 9.0.93. Not sure how to help more but I just wanted to 
chime in and say that Ahmed is not the only one still seeing the problem 
even with the newest version.


What we need both to track down the root cause (I have my suspicions but 
no proof) is a test case that triggers the issue. The simpler the test 
case the better but at this point I'd settle for anything that triggered 
the issue in a reasonable time frame.


Mark



On 2024/10/04 10:00:03 Ahmed Ashour wrote:
 > > How rare? Once in how many requests? Can you trigger this via 
automated testing e.g. with wrk?
 > After working for some time (from 10 minutes to an hour), making a 
request to a page (with subsequent JS/images) every one minute, the 
issue is shown, happens on Chrome and Brave.
 > The requests with wrk are all successful, tested for one hour, using 
the default settings.
 > Background:- There is a Tomcat server which is restarted daily, to 
clean the auto deploy of the applications.- Three members have seen the 
issue, in the last 3 days.- The main application is protected by basic 
authentication- Once the issue happens, even the sample non-protected 
application (html/js) is not accessible.

 >
 > > Does setting discardRequestsAndResponses="true" help at all?
 >
 > No, it doesn't.
 > The settings now are:
 > className="org.apache.coyote.http2.Http2Protocol" readTimeout="2"/>

 >
 > which still gives the error.
 > The current workaround is to remove the UpgradeProtocol element.
 >
 > I wonder if low-level logs, or network sniffing can help, as it is a 
secure connection.

 > Thanks,Ahmed

-
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

AW: Migrating from Tomcat 9.0.88 to Tomcat 10.1.30 on windows machine with JDK 21 LTS

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Sajid,

> -Ursprüngliche Nachricht-
> Von: Sajid Hussain 
> Gesendet: Dienstag, 8. Oktober 2024 13:21
> An: users@tomcat.apache.org
> Betreff: Migrating from Tomcat 9.0.88 to Tomcat 10.1.30 on windows
> machine with JDK 21 LTS
> 
> Hi,
> 
> I was using tomcat 9 with JDK 17 on windows. My java application was using
> 2.7.18. Now I'm migrating my application spring version to 3.3.4 with Tomcat
> 10.1.30 and JDK 21. I have upgraded the version in my java project and fix the
> hibernate error migrating from 5 to 6. Now my application start on tomcat 10.
> But after few request JVM consume the maximum memory (I set it 3GB max)
> and cup usage to 90-98%. I set windows service priority to low and it take 80-
> 90% hence my application stop responding. Here is the thread dum for the
> tomcat.Not getting any clue whats causing to tomcat high CPU and memory
> usage.
> 
> 
> 
> Regards,
> 
> Sajid Hussain

the CPU usage is often high when the garbage collector can't free up sufficient 
memory.
The memory usage shows little spikes going up and down, like a little sawtooth 
in this case.
If this is the case, I would recommend creating a heap dump and analyze the 
dump, what is occupying the memory.
Eclipse MAT will assist you in analyzing the heap dump.

Greetings, Thomas

Re: Migrating from Tomcat 9.0.88 to Tomcat 10.1.30 on windows machine with JDK 21 LTS

[Mark Thomas]

On 08/10/2024 05:21, Sajid Hussain wrote:

Hi,

I was using tomcat 9 with JDK 17 on windows. My java application was 
using 2.7.18. Now I'm migrating my application spring version to 3.3.4 
with Tomcat 10.1.30 and JDK 21. I have upgraded the version in my java 
project and fix the hibernate error migrating from 5 to 6. Now my 
application start on tomcat 10. But after few request JVM consume the 
maximum memory (I set it 3GB max) and cup usage to 90-98%. I set windows 
service priority to low and it take 80-90% hence my application stop 
responding. Here is the thread dum for the tomcat.Not getting any clue 
whats causing to tomcat high CPU and memory usage.


A profiler (I use YourKit because they give free licenses to OSS 
develoeprs but other profilers are avialable) will tell you more about 
what is going on than a single stack trace.


Is this a Spring Boot app? Is it packaged as a JAR or a WAR?

How are you running this as a Windows service? If you are using Apache 
Commons Daemon (the default way to run Tomcat as a Windows service) then 
this might be useful:

https://issues.apache.org/jira/projects/DAEMON/issues/DAEMON-460

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using HTTP 1.1 over a configured HTTP2 Connector

[Mark Thomas]

On 04/10/2024 20:32, Anurag Sharma wrote:

HI Mark And Christopher,

Apologies for the late response,

Tomcat act as a reverse proxy to 3rd party legacy system.   We have recently 
upgraded Tomcat to use HTTP/2 protocol; this causes the legacy system not to 
render and get an error message when rendering.  Tomcat application war acts as 
a reverse proxy (which means all requests hit the web app then we have Camel 
Proxy to proxy to the endpoint).

Browser-->HTT2-->Tomcat Web App (Reverse Proxy) -->HTT1.1 --> 3rd Party UI

Since Tomcat is configured with HTTP protocol, the browser automatically 
negotiates the http2 protocol.  Is there any way to configure some path ( 
/context-path/XXX)  would still needs to be HTTP 1.1.


No.


Currently, the only option is for us to open different connector ports strictly 
with HTTP 1.1 and have traffic land here.  Is there any better approach for 
this ?


The reverse proxy should work equally well whether the client uses 
HTTP/1.1, HTTP/2 or AJP. My recommendation would be to fix the bug(s) in 
the reverse proxy code that cause it to break with HTTP/2.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Using HTTP 1.1 over a configured HTTP2 Connector

[Mark Thomas]

On 01/10/2024 06:15, Anurag Sharma wrote:

Dear Tomcat Team,

I hope this message finds you well.

I am currently facing a challenge regarding the use of HTTP/1.1 for specific 
API endpoints within a servlet configured for HTTP/2. My browser defaults to 
HTTP/2, which complicates the situation as I need to proxy some APIs to a 
server that only supports HTTP/1.1.
Is there a workaround available to enforce HTTP/1.1 for these particular 
endpoints?


It isn't clear from the above which component needs to talk to which 
using what protocol.


Servlets don't care whether the request is received via HTTP/1.1 or HTTP/2.

Tomcat will happily process requests for the same servlet using HTTP/1.1 
or HTTP/2 depending on client support.


Outgoing requests from Tomcat to external services are outside of the 
control of Tomcat and are entirely an application concern.


Can you be more precise about what the problem is?

Mark




Here is out server.xml config. All request from our app is http2 protocol.




 

   

 

 

 


Thank you so much for your help.



Thanks and Regards,
Anurag Sharma




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: net::ERR_HTTP2_PROTOCOL_ERROR with 10.1.30

[Mark Thomas]

On 30/09/2024 07:38, Ahmed Ashour wrote:

Hi all,
Even though the regression should have been fixed in 10.1.30, our team still 
sees it around once weekly. Twice so far.
With 10.1.29 it was very frequent, that the server can't be used, but with 
10.1.30 it is much less, but sadly it seems on rare occasions to occur.


How rare? Once in how many requests? Can you trigger this via automated 
testing e.g. with wrk?



I understand the difficulty of reproducing it, but a hint about using Chrome 
could be beneficial, as it seems it doesn't happen with Firefox for example.
Remarking the UpgradeProtocol configuration makes the team uses the application 
server again.

Please let me know if anything to be done to help in this regard.


Does setting discardRequestsAndResponses="true" help at all?

Mark




Thanks a lot,Ahmed Ashour



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Setting Transfer-Encoding: chunked

[Mark Thomas]

On 30/09/2024 07:37, Lazar Kirchev wrote:

Hello,

Tomcat automatically adds header Transfer-Encoding: chunked if on http 1.1,
the response code supports body and there is no Connection: Close header
(Tomcat 9's code -
https://github.com/apache/tomcat/blob/372f3cefe6225b58fcdae7c344d81396b8e08570/java/org/apache/coyote/http11/Http11Processor.java#L935
).
However, if the application has already set this header, then the header
gets duplicated. There is no check if the header is already present. Is
this intended behavior?


Applications should not, under any circumstances, be setting the HTTP 
header "Transfer-Encoding: chunked".


Applications do not have sufficient control over the bytes on the wire 
to manually control chunked encoding.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Elapsed Time incorrect for HTTP/2.0?

[Mark Thomas]

On 24/09/2024 12:40, Thomas Meyer wrote:



Am 24. September 2024 10:44:46 MESZ schrieb Mark Thomas :

On 24/09/2024 08:59, Thomas Meyer wrote:

Hi,

We see sometimes elapsed time values with over 100 million milliseconds and 
status code 500 in the Tomcat logs for HTTP/2.0 connections.

Is that expected or a bug?


Is it just the large elapsed times that are unexpected or are the 500 status 
codes unexpected as well?


Mhh, now that you mention it, I think I would have expected a 200 return code 
for this request, which actually took 113 seconds what I can see from the logs, 
but the frontend has a timeout of 60 seconds, so the request was probably 
aborted by the frontend.


So there might be an issue with elapsed time when we receive a stream 
reset from the client. I'll take a look at the code.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Website inconsistency

[Mark Thomas]

On 26/09/2024 16:05, Doug Whitfield wrote:

Hi Folks,

On the left sidebar of the website the download is for “Tomcat 10” while the 
Documentation is for “Tomcat 10.1”. Now, between Download and Documentation 
things are consistent.

I don’t think this is strictly speaking wrong, but I don’t see any good reason 
for it and I do think it is a bit confusing. Is there a good reason that I am 
missing?


The download links refer to just the major version. The docs refer to 
the major and minor.


The reason is that sometimes (eg 10.0.x and 10.1.x) we have multiple 
minors of the same major being released at the same time. The download 
pages are per major but the docs are the latest release of each minor.


It looks slightly odd at the moment now you mention it but not enough 
I'm motivated to go and fix it.


Do we want a single download page for all Tomcat versions?

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Elapsed Time incorrect for HTTP/2.0?

[Thomas Meyer]

Am 24. September 2024 10:44:46 MESZ schrieb Mark Thomas :
>On 24/09/2024 08:59, Thomas Meyer wrote:
>> Hi,
>> 
>> We see sometimes elapsed time values with over 100 million milliseconds and 
>> status code 500 in the Tomcat logs for HTTP/2.0 connections.
>> 
>> Is that expected or a bug?
>
>Is it just the large elapsed times that are unexpected or are the 500 status 
>codes unexpected as well?

Mhh, now that you mention it, I think I would have expected a 200 return code 
for this request, which actually took 113 seconds what I can see from the logs, 
but the frontend has a timeout of 60 seconds, so the request was probably 
aborted by the frontend.

>
>If the 500s are expected (or at least explainable) it is possible the elapsed 
>time calculation isn't right for some error conditions.
>
>Mark
>
>
>> 
>> I assume this is because of http2 multiplexing maybe?
>> 
>> Tomcat version is 10.1.30
>> 
>> Mfg
>> Thomas
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: tomcat startup error, IBM DB2 related (database)

[Mark Thomas]

On 24/09/2024 08:58, Michael Lau wrote:


here's a clip of the error from the cmd window of my friend:

0-Sep-2024 13:51:51.584 INFO [Timer-0]
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading
Illegal access: this web application instance has been stopped already.
Could not load [com/ibm/db2/jcc/DB2JccConfiguration.properties]. The
following stack trace is thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access.

 java.lang.IllegalStateException: Illegal access: this web
application instance has been stopped already. Could not load
[com/ibm/db2/jcc/DB2JccConfiguration.properties]. The following stack trace
is thrown for debugging purposes as well as to attempt to terminate the
thread which caused the illegal access.


That is an error triggered when stopping the web application.

I suggest the following.

Stop the Tomcat instance.
Clear the logs directory (move the files somewhere else so you have a 
copy if you need them).

Start the Tomcat instance.
Look for errors in the logs. Start at the beginning. Fix the first error 
that occurs and then repeat this process.


The first error usually triggers multiple further errors. If you don't 
fix the first error first you will waste a huge amount of time fixing 
symptoms rather than the root cause.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Elapsed Time incorrect for HTTP/2.0?

[Mark Thomas]

On 24/09/2024 08:59, Thomas Meyer wrote:

Hi,

We see sometimes elapsed time values with over 100 million milliseconds and 
status code 500 in the Tomcat logs for HTTP/2.0 connections.

Is that expected or a bug?


Is it just the large elapsed times that are unexpected or are the 500 
status codes unexpected as well?


If the 500s are expected (or at least explainable) it is possible the 
elapsed time calculation isn't right for some error conditions.


Mark




I assume this is because of http2 multiplexing maybe?

Tomcat version is 10.1.30

Mfg
Thomas



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Elapsed Time incorrect for HTTP/2.0?

[Thomas Meyer]

Hi,

We see sometimes elapsed time values with over 100 million milliseconds and 
status code 500 in the Tomcat logs for HTTP/2.0 connections.

Is that expected or a bug?

I assume this is because of http2 multiplexing maybe?

Tomcat version is 10.1.30

Mfg
Thomas 

Re: tomcat query

[Mark Thomas]

On 23/09/2024 13:50, Rachana Kharchane wrote:

Hi Team,

I Have few queries

How can we ensure the old  config is kept in place post installing a new tomcat 
version?

Do we have options to backup the configuration and reapply after new version 
install of Tomcat?


Read RUNNING.txt in the root of your Tomcat distribution.

Look for "Advanced Configuration - Multiple Tomcat Instances"

CATALINA_BASE points to your instance.

CAATALINA_HOME points to the binaries.

Upgrades are then as simple as:
- unpack new version
- stop instance
- update CATALINA_HOME to point to new version
- start instance

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2024-38286 Apache Tomcat - Denial of Service

[Mark Thomas]

CVE-2024-38286 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M20
Apache Tomcat 10.1.0-M1 to 10.1.24
Apache Tomcat 9.0.13 to 9.0.89

Description:
Tomcat, under certain configurations on any platform, allows an attacker 
to cause an OutOfMemoryError by abusing the TLS handshake process.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M21 or later
- Upgrade to Apache Tomcat 10.1.25 or later
- Upgrade to Apache Tomcat 9.0.90 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Ozaki, North Grid Corporation


History:
2024-07-03 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[SECURITY] CVE-2024-46544 Apache mod_jk - Information Disclosure / Denial of Service

[Mark Thomas]

CVE-2024-46544 Apache mod_jk - Information Disclosure / DoS

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
- JK 1.2.9-1.2.49 (mod_jk on Unix like platforms only)

Description:
Incorrect default permissions for the memory mapped file configured by 
the JkShmFile directive on Unix like systems allows local users to view 
and/or modify the contents of the shared memory containing mod_jk 
configuration and status information. This could result in information 
disclosure and/or denial of service.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to mod_jk 1.2.50 or later

History:
2024-09-23 Original advisory

References:
[1] https://tomcat.apache.org/security-jk.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Tld Scanner and tomcat-coyote-ffm

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Mark,

> -Ursprüngliche Nachricht-
> Von: Mark Thomas 
> Gesendet: Samstag, 21. September 2024 12:02
> An: users@tomcat.apache.org
> Betreff: Re: Tld Scanner and tomcat-coyote-ffm
> 
> On 21/09/2024 10:45, Thomas Hoffmann (Speed4Trade GmbH) wrote:
> > Hello,
> >
> > the recent Tomcat 10.1 versions seem to contain the file
> > tomcat-coyote-ffm.jar This triggers a warning that the TldScanner didn't 
> > find
> any Tld inside the jar:
> > FEIN [main]
> > org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
> > files were found in ... tomcat-coyote-ffm.jar
> >
> > Should the jar be added to the default exclude list within Tomcat?
> 
> It is as of 10.1.29.
> 
> Mark
> 

Thanks for the quick reply!
I think my custom jarsToSkip attriubte in the server.xml overrides the 
Catalina.properties and that’s caused the warning.
Sorry for bothering!
Have a nice weekend!

Re: Tld Scanner and tomcat-coyote-ffm

[Mark Thomas]

On 21/09/2024 10:45, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,

the recent Tomcat 10.1 versions seem to contain the file tomcat-coyote-ffm.jar
This triggers a warning that the TldScanner didn't find any Tld inside the jar:
FEIN [main] org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in ... tomcat-coyote-ffm.jar

Should the jar be added to the default exclude list within Tomcat?


It is as of 10.1.29.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tld Scanner and tomcat-coyote-ffm

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

the recent Tomcat 10.1 versions seem to contain the file tomcat-coyote-ffm.jar
This triggers a warning that the TldScanner didn't find any Tld inside the jar:
FEIN [main] org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD 
files were found in ... tomcat-coyote-ffm.jar

Should the jar be added to the default exclude list within Tomcat?

Greetings,
Thomas

Re: Error migrating to Tomcat 10.1

[Mark Thomas]

On 19/09/2024 21:16, Campbell, Lance wrote:

I think I might have found the issue.  I built my web app with Java 8 and 
Tomcat 9 using version 4.0 of the web-app species originally.  This was a 
servlet mapping I had:


 NavigationServlet
 *.navigation
   

Notice the url-pattern. It has *.navigation.

Now I am using Java 17 and Tomcat 10.1 with version 5.0 of the web-app specs.  
Is the above allowed with a URL redirection?


Yes.



 I think the *.xyz might be the issue with HttpServletResponse sendRedirect .

> > Thoughts?

Unlikely related given the error you are seeing.

Mark




Thanks


-Original Message-
From: Mark Thomas 
Sent: Thursday, September 19, 2024 2:52 PM
To: users@tomcat.apache.org
Subject: Re: Error migrating to Tomcat 10.1

On 19/09/2024 20:19, Campbell, Lance wrote:

I am using the latest Tomcat 10.1

Java 17

Apache Web server communicates with an application server running tomcat.  The 
application name is webtools.

I am migrating a working app from Tomcat 9 to Tomcat 10.1.


Does your AJP connector in Tomcat 9 have a packetSize attribute? If yes, you 
need to copy that across to 10.1

You can also check your work configuration on httpd for max_packet_size.
The two values have to agree.

Mark




I am getting this error in the tomcat app after sending a web request. It seems 
like it is starting to load things. Then I see the below:

19-Sep-2024 13:54:54.086 INFO [main]
org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of
deployment descriptor
[/../webtools/conf/Catalina/localhost/ROOT.xml] has finished in
[3,782] ms
19-Sep-2024 13:54:54.089 INFO [main]
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler
["ajp-nio-0:0:0:0:0:0:0:0-8149"]
19-Sep-2024 13:54:54.101 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [3873]
milliseconds
19-Sep-2024 13:54:55.332 SEVERE [ajp-nio-0:0:0:0:0:0:0:0-8149-exec-1] 
org.apache.coyote.ajp.AjpMessage.checkOverflow Overflow error for buffer adding 
[113] bytes at position [8085]
  java.lang.ArrayIndexOutOfBoundsException
  at 
org.apache.coyote.ajp.AjpMessage.checkOverflow(AjpMessage.java:242)
  at 
org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:211)
  at 
org.apache.coyote.ajp.AjpMessage.appendByteChunk(AjpMessage.java:197)
  at 
org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:181)
  at 
org.apache.coyote.ajp.AjpProcessor.prepareResponse(AjpProcessor.java:991)
  at 
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:377)
  at org.apache.coyote.Response.action(Response.java:210)
  at org.apache.coyote.Response.commit(Response.java:464)
  at 
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:285)
  at 
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:244)
  at 
org.apache.catalina.connector.Response.finishResponse(Response.java:421)
  at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:373)
  at 
org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:431)
  at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
  at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:904)
  at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1741)
  at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
  at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1190)
  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(Thread.java:840)

This is my server.xml file:

 









  

  




  



Error in the jk.log on apache running mod_jk:

[Thu Sep 19 14:11:06.896 2024] [18915:140692079404800] [error]
ajp_unmarshal_response::jk_ajp_common.c (786): (webtools) NULL header
value [Thu Sep 19 14:11:06.896 2024] [18915:140692079404800] [error]
ajp_process_callback::jk_ajp_common.c (1937): (webtools)
ajp_unmarshal_response failed [Thu Sep 19 14:11:06.896 2024]
[18915:140692079404800] [info] ajp_service::jk_ajp_common.c (2774):
(webtools) sending request to tomcat failed (recoverable), because of
server error (attempt=1) [Thu Sep 19 14:11:06.997 2024] [18915:140692079404800] 
[info] ajp_send_request::jk_ajp_common.c (1623): (webtools) did not receive 
END_RESPONSE, closing socket -1 [Thu Sep 19 14:11:07.127 2024] 
[18915:140692079404800] [error] ajp_unmarshal_response::jk_a

Re: Error migrating to Tomcat 10.1

[Mark Thomas]

On 19/09/2024 20:19, Campbell, Lance wrote:

I am using the latest Tomcat 10.1

Java 17

Apache Web server communicates with an application server running tomcat.  The 
application name is webtools.

I am migrating a working app from Tomcat 9 to Tomcat 10.1.


Does your AJP connector in Tomcat 9 have a packetSize attribute? If yes, 
you need to copy that across to 10.1


You can also check your work configuration on httpd for max_packet_size. 
The two values have to agree.


Mark




I am getting this error in the tomcat app after sending a web request. It seems 
like it is starting to load things. Then I see the below:

19-Sep-2024 13:54:54.086 INFO [main] 
org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of 
deployment descriptor [/../webtools/conf/Catalina/localhost/ROOT.xml] has 
finished in [3,782] ms
19-Sep-2024 13:54:54.089 INFO [main] org.apache.coyote.AbstractProtocol.start Starting 
ProtocolHandler ["ajp-nio-0:0:0:0:0:0:0:0-8149"]
19-Sep-2024 13:54:54.101 INFO [main] org.apache.catalina.startup.Catalina.start 
Server startup in [3873] milliseconds
19-Sep-2024 13:54:55.332 SEVERE [ajp-nio-0:0:0:0:0:0:0:0-8149-exec-1] 
org.apache.coyote.ajp.AjpMessage.checkOverflow Overflow error for buffer adding 
[113] bytes at position [8085]
 java.lang.ArrayIndexOutOfBoundsException
 at 
org.apache.coyote.ajp.AjpMessage.checkOverflow(AjpMessage.java:242)
 at 
org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:211)
 at 
org.apache.coyote.ajp.AjpMessage.appendByteChunk(AjpMessage.java:197)
 at 
org.apache.coyote.ajp.AjpMessage.appendBytes(AjpMessage.java:181)
 at 
org.apache.coyote.ajp.AjpProcessor.prepareResponse(AjpProcessor.java:991)
 at 
org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:377)
 at org.apache.coyote.Response.action(Response.java:210)
 at org.apache.coyote.Response.commit(Response.java:464)
 at 
org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:285)
 at 
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:244)
 at 
org.apache.catalina.connector.Response.finishResponse(Response.java:421)
 at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:373)
 at 
org.apache.coyote.ajp.AjpProcessor.service(AjpProcessor.java:431)
 at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
 at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:904)
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1741)
 at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
 at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1190)
 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(Thread.java:840)

This is my server.xml file:




   
   
   
   
   

   

 

 

   

   
 
   


Error in the jk.log on apache running mod_jk:

[Thu Sep 19 14:11:06.896 2024] [18915:140692079404800] [error] 
ajp_unmarshal_response::jk_ajp_common.c (786): (webtools) NULL header value
[Thu Sep 19 14:11:06.896 2024] [18915:140692079404800] [error] 
ajp_process_callback::jk_ajp_common.c (1937): (webtools) ajp_unmarshal_response 
failed
[Thu Sep 19 14:11:06.896 2024] [18915:140692079404800] [info] 
ajp_service::jk_ajp_common.c (2774): (webtools) sending request to tomcat 
failed (recoverable), because of server error (attempt=1)
[Thu Sep 19 14:11:06.997 2024] [18915:140692079404800] [info] 
ajp_send_request::jk_ajp_common.c (1623): (webtools) did not receive 
END_RESPONSE, closing socket -1
[Thu Sep 19 14:11:07.127 2024] [18915:140692079404800] [error] 
ajp_unmarshal_response::jk_ajp_common.c (786): (webtools) NULL header value
[Thu Sep 19 14:11:07.127 2024] [18915:140692079404800] [error] 
ajp_process_callback::jk_ajp_common.c (1937): (webtools) ajp_unmarshal_response 
failed
[Thu Sep 19 14:11:07.127 2024] [18915:140692079404800] [info] 
ajp_service::jk_ajp_common.c (2774): (webtools) sending request to tomcat 
failed (recoverable), because of server error (attempt=2)
[Thu Sep 19 14:11:07.128 2024] [18915:140692079404800] [error] 
ajp_service::jk_ajp_common.c (2795): (webtools) connecting to tomcat failed 
(rc=-3, errors=1, client_errors=0).
[Thu Sep 19 14:11:07.128 2024] [18915:140692079404800] [info] 
jk_handler::mod_jk.c (2991): Service error=-3 for worker=webtools


Thanks,

Lance Campbell




-
To unsubs

Re: [Bug 69325] Tomcat not allowing CRLF characters in Request headers

[Mark Thomas]

On 17/09/2024 13:46, manjosh ramesh wrote:

Hi Mark,
What is strange is that we are obtaining the cookie by triggering an HTTP 
request to a spring-boot application running on Tomcat. The same tomcat server 
adds '^M$' at the end of each line in the response.
If we redirect this response to a file and use a cookie, Tomcat rejects it.


HTTP headers use CRLF as a line terminator.

If you write that "as-is" to a file you will end with with CRLF line 
terminators in that file.


If you then read the file assuming the line terminator is LF then you 
will, effectively, insert the CR (^M) characters at the end of every line.


You need to ensure that you read and write the file using the same line 
terminator.


Mark



Regards,
Manjosh Ramesh

 On Tuesday, September 17, 2024 at 02:51:28 PM GMT+5:30, Mark Thomas 
 wrote:
  
  On 17/09/2024 04:44, manjosh ramesh wrote:


   Hi,ok, so this was a bug in older tomcat release and has been fixed in newer 
version, is it?


Yes.


Could you please share the bug id for this change?


No. Not every fix is associated with a bug ID since not every issue is
raised via the issue tracker. This is such an issue.

You haven't been specific about which version worked and which one
didn't although you do mention the issue appearing when you upgraded to
8.5.99.

If I had to guess then I'd guess the change the uncovered the issue in
your cookie header was the one that meant CRCRLF was rejected as a line
terminator. That was in 8.5.82.

I'll note that Tomcat 8.5.x reached end of life on 31 March 2024 and is
no longer supported by the ASF.

Extended support is available from various commercial entities for older
versions of Tomcat. I would strongly recommend that anyone considering
one of those options looks carefully at the provider's claims of Tomcat
expertise. Or just upgrade to an ASF supported version.


Because the older tomcat allows this type of request.


Quite possibly. There has been a general tightening up of HTTP request
parsing over time. Partly in response to reported security
vulnerabilities, partly as a preventative measure against the
possibility of future vulnerabilities.


Also Our cookie is complient. We are not able to find what is not complient in 
our cookie.


No, it isn't. CR (^M) is not a permitted character in an HTTP request
header so your cookie header is not valid.


It only works when we remove '^M' or '^M$' from the end of line in our cookie.


As expected. Once you make the HTTP request specification complaint,
Tomcat will accept it.

Mark



Regards,Manjosh Ramesh

       On Monday, September 16, 2024 at 09:37:22 AM GMT+5:30, 
 wrote:
   
   https://bz.apache.org/bugzilla/show_bug.cgi?id=69325


Chuck Caldarale  changed:

             What    |Removed                    |Added

               Status|UNCONFIRMED                |RESOLVED
           Resolution|---                        |INVALID

--- Comment #3 from Chuck Caldarale  ---
As previously stated, any further discussion must be on the Tomcat users'
mailing list. Do not reopen this bugzilla entry.




-
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: [Bug 69325] Tomcat not allowing CRLF characters in Request headers

[Mark Thomas]

On 17/09/2024 04:44, manjosh ramesh wrote:


  Hi,ok, so this was a bug in older tomcat release and has been fixed in newer 
version, is it?


Yes.


Could you please share the bug id for this change?


No. Not every fix is associated with a bug ID since not every issue is 
raised via the issue tracker. This is such an issue.


You haven't been specific about which version worked and which one 
didn't although you do mention the issue appearing when you upgraded to 
8.5.99.


If I had to guess then I'd guess the change the uncovered the issue in 
your cookie header was the one that meant CRCRLF was rejected as a line 
terminator. That was in 8.5.82.


I'll note that Tomcat 8.5.x reached end of life on 31 March 2024 and is 
no longer supported by the ASF.


Extended support is available from various commercial entities for older 
versions of Tomcat. I would strongly recommend that anyone considering 
one of those options looks carefully at the provider's claims of Tomcat 
expertise. Or just upgrade to an ASF supported version.



Because the older tomcat allows this type of request.


Quite possibly. There has been a general tightening up of HTTP request 
parsing over time. Partly in response to reported security 
vulnerabilities, partly as a preventative measure against the 
possibility of future vulnerabilities.



Also Our cookie is complient. We are not able to find what is not complient in 
our cookie.


No, it isn't. CR (^M) is not a permitted character in an HTTP request 
header so your cookie header is not valid.



It only works when we remove '^M' or '^M$' from the end of line in our cookie.


As expected. Once you make the HTTP request specification complaint, 
Tomcat will accept it.


Mark



Regards,Manjosh Ramesh

 On Monday, September 16, 2024 at 09:37:22 AM GMT+5:30, 
 wrote:
  
  https://bz.apache.org/bugzilla/show_bug.cgi?id=69325


Chuck Caldarale  changed:

           What    |Removed                    |Added

             Status|UNCONFIRMED                |RESOLVED
         Resolution|---                        |INVALID

--- Comment #3 from Chuck Caldarale  ---
As previously stated, any further discussion must be on the Tomcat users'
mailing list. Do not reopen this bugzilla entry.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 11.0.0-M26 (beta) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M26 (beta).

Apache Tomcat 11 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 available to aid this process.

Apache Tomcat 11.0.0-M26 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.0-M25 include:

- Fix the regression in HTTP/2 support introduced in 11.0.0-M25.

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: Question about upgrading tomcat-embed-core from 10.1.20 to 10.1.25

[Mark Thomas]

On 15/09/2024 00:37, KARR, DAVID wrote:

We build SpringBoot applications that reference "tomcat-embed-core" from 
"spring-boot-starter-jersey". We currently end up with version 10.1.20 of 
tomcat-embed-core, using spring-boot 3.2.5.  There is apparently a CVE for that version of 
tomcat-embed-core (I don't have the CVE handy right now).  The resolution is to replace it with 
version 10.1.25.  That, being a patch version, seems like a safe upgrade from a functionality point 
of view. Are there any known issues from performing that upgrade?


There is a known issue with non-blocking reads and chunked encoding in 
10.1.24 to 10.1.29.


I'd wait for 10.1.30 in a few days (HTTP/2 is broken in 10.1.29).

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat: HTTP/2 regression in 11.0.0-M25, 10.1.29, 9.0.94

[Mark Thomas]

A regression has been reported and confirmed in the latest Tomcat 
releases that affects configurations using HTTP/2.


The affected versions are:
- 11.0.0-M25
- 10.1.29
- 9.0.94

The regression can be worked around by setting:

discardRequestsAndResponses="true"

on the UpgradeProtocol element for HTTP/2.

We currently expect to provide releases with a fix for this regression 
next week.


For more information, see the associated bug report:
https://bz.apache.org/bugzilla/show_bug.cgi?id=69320

- The Apache Tomcat team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: net::ERR_HTTP2_PROTOCOL_ERROR errors in version 10.1.29

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,
thank you for the quick reply!
I will wait for the next release / fix.

> -Ursprüngliche Nachricht-
> Von: Rémy Maucherat 
> Gesendet: Freitag, 13. September 2024 12:48
> An: Tomcat Users List 
> Betreff: Re: net::ERR_HTTP2_PROTOCOL_ERROR errors in version 10.1.29
> 
> On Fri, Sep 13, 2024 at 11:58 AM Thomas Hoffmann (Speed4Trade GmbH)
>  wrote:
> >
> > Hello,
> > after upgrading from 10.1.25 to 10.1.29 I experience many
> net::ERR_HTTP2_PROTOCOL_ERROR in Edge and Chrome.
> > Firefox shows NS_ERROR_NET_RESET.
> > The website doesn't fully render.
> >
> > Access-Log shows several HTTP 500 errors for static resources.
> > The other logfiles don't show any errors.
> >
> > Does anybody observer the same issues?
> 
> You can use 10.1.28 instead for now, the regression is being worked on.
> 
> Rémy
> 
> > My connector looks like:
> >
> >  protocol="org.apache.coyote.http11.Http11NioProtocol"
> >
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImple
> mentation"
> >maxThreads="150" minSpareThreads="25"
> >URIEncoding="UTF-8" useBodyEncodingForURI="false"
> >enableLookups="false" disableUploadTimeout="true"
> >acceptCount="100" scheme="https" secure="true"
> >SSLEnabled="true"
> >compression="force">
> >  className="org.apache.coyote.http2.Http2Protocol"  />
> >  > disableSessionTickets="true"
> > honorCipherOrder="false"
> > protocols="+TLSv1.2,+TLSv1.3">
> >  certificateFile="localhost.pem"   type="RSA"/>
> > 
> > 
> >
> >
> > Thanks in advance!
> > Thomas
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

net::ERR_HTTP2_PROTOCOL_ERROR errors in version 10.1.29

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,
after upgrading from 10.1.25 to 10.1.29 I experience many 
net::ERR_HTTP2_PROTOCOL_ERROR in Edge and Chrome.
Firefox shows NS_ERROR_NET_RESET.
The website doesn't fully render.

Access-Log shows several HTTP 500 errors for static resources.
The other logfiles don't show any errors.

Does anybody observer the same issues?

My connector looks like:









Thanks in advance!
Thomas

Re: Max parameters limit

[Thomas Meyer]

Hi,

This sounds more like a security requirement. Such constraints are usually 
implemented in the frontend, i.e. the http reverse proxy with mod_security or 
an explicit web application firewall.

Any chance to implement it in a similar way in your setup?

Mfg
Thomas

Am 11. September 2024 18:31:01 MESZ schrieb Christopher Schultz 
:
>All,
>
>Does anyone know if there is a way to limit the number of HTTP parameters in a 
>POST request but explicitly allow more parameters for, say, a small set of 
>specific URLs?
>
>Asking for a friend.
>
>-chris
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Trying to Resolve a Java Version Vulnerability I'm Using for Tomcat

[Mark Thomas]

Michael,

What is the error message when Tomcat doesn't start?

We may also need to see relevant parts of all the log files in Tomcat's 
logs directory.


Mark





On 11/09/2024 14:13, Ferrick, Michael wrote:

Hello,

The powers above have notified me that the Java version 9.0.1.0 (x64) that I am 
using with Apache Tomcat 9.0.84 has a vulnerability on my Windows servers (OS 
2019) and MUST be remediated. That means use another Java version!

I removed Java 9.0.1 (64-bit) and Java (tm) SE Development Kit 9.0 (64-bit) 
from the Control Panel (It notified me that it would stop Tomcat) and I 
installed jdk-8u421-windows-x64.exe in the default location of C:Program 
Files\Java, which was the same location as the original 9.0.1.0 version.

Apache Software is located on E:\Program Files\Apache Software 
Foundation\Tomcat 9.0.

I opened Services and attempted to Start Apache Tomcat and I got an error 
message. The only thing the message meant to me is that Tomcat failed to start. 
I'm not an SME (Subject Matter Expert) on JAVA or Tomcat however if the content 
is important to resolve let me know.

I removed Java 8u421 from the Control Panel (Both the Jav SE Dev tool Kit and 
Java 8.421 (64-bit)).

I re-installed jdk-9.0.1_windows-64_bin.exe and checked Control Panel to 
confirm both Java and the toolkit was also installed.

I re-opened Services and was able to restart Apache Tomcat.

I then downloaded Java 8u422-b05-windows-x64 and using the same procedures as above 
uninstalled Java 9.0.1 and installed java 8.422 and it failed to start Apache Tomcat, so 
I once again had to revert to the "vulnerable" Java 9.0.1.

Can anyone tell me what non-vulnerable version of Java will work with Tomcat 
9.0.84 or what I am missing to make the 8.xx versions I have work? I can't 
simply upgrade Apache Tomcat as there are just too many developers entrenched 
in this version.

Thank you,
Mike

_
The information contained in this email and any attachments have been 
classified as limited access and/or privileged State Street 
information/communication and is intended solely for the use of the named 
addressee(s). If you are not an intended recipient or a person responsible for 
delivery to an intended recipient, please notify the author and destroy this 
email. Any unauthorized copying, disclosure, retention or distribution of the 
material in this email is strictly forbidden.
Go green. Consider the environment before printing this email.



Information Classification: General




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 11.0.0-M25 (beta) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M25 (beta).

Apache Tomcat 11 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 available to aid this process.

Apache Tomcat 11.0.0-M25 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.0-M24 include:

- Implement the recent clarification from the Jakarta Servlet project
  that if a content length is declared then once that many bytes have
  been written to the response, further writes should trigger an
  IOException

- If an HTTP/2 client resets a stream before the request body is fully
  written, ensure that any ReadListener is notified via a call to
  ReadListener.onErrror()

- An Exception being thrown during WebSocket message processing (e.g. in
  a method annotated with @onMessage) should not automatically cause the
  connection to close. The application should handle the exception and
  make the decision whether or not to close the connection.

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: Tomcat 10.1 and context.xml

[Mark Thomas]

On 10/09/2024 20:21, charliedidon...@gmail.com wrote:

I have war file in Tomcat 10.1 with a context.xml file included in the
META-INF folder.

It's contents are





I am getting 404s from my app and was wondering if this is still supported
under 10.1 as it was under 9.0


Support is unchanged. From the 9.0.x docs:

The value of this field must not be set unless the Context element is 
defined in server.xml or the docBase is not located under the Host's 
appBase.


The above setting is not valid on any currently supported version of 
Tomcat including 9.0.x.


A check of the archives show that the same (or very similar) text exists 
in the docs all the way back to 5.5.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Jersey on Tomcat 10.1

[Thomas Meyer]

Hi,

Looks correct, see example from GitHub:

https://github.com/eclipse-ee4j/jersey/blob/3.1/examples/servlet3-webapp/pom.xml

But I assume that Jersey 3.1.x does implement jax-rs 3.1, so maybe that's the 
reason it cannot find this class.

Mfg
Thomas 


Am 10. September 2024 20:07:07 MESZ schrieb "Jürgen Weber" :
>Hi,
>
>I am looking for a working minimal Jersey on Tomcat 10.1 Maven based
>REST example.
>What I found all give ClassNotFoundExceptions.
>
>Anybody knows an example on github?
>
>Does Jersey even work on Tomcat?
>
>Thx
>
>
>java.lang.ClassNotFoundException: org.glassfish.jersey.client.ClientConfig
>java.lang.NoClassDefFoundError: jakarta/ws/rs/core/EntityPart
>
>org.glassfish.jersey
>jersey-bom
>
>
>jakarta.ws.rs
>jakarta.ws.rs-api
>3.0.0
>
>org.glassfish.jersey.containers
>jersey-container-servlet
>
>org.glassfish.jersey.inject
>jersey-hk2
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: Nothing but 404 errors

[Mark Thomas]

On 05/09/2024 16:24, David Rush wrote:

Doh!  I have resolved it.

When creating my CATALINA_BASE/conf, server.xml was the only file that I
copied into it (in my defense it's the only file explicitly mentioned as
going into the conf directory under the CATALINA_BASE section on running
multiple tomcat instances in the RUNNING.txt file).

Copying EVERYTHING from CATALINA_HOME/conf to CATALINA_BASE/conf resolved
the issue.


No web.xml meant no default servlet and no JSP servlet defined. Hence 
static files and JSPs will have returned 404s.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: JNDI connection pool in Tomcat 10.1

[Mark Thomas]

On 04/09/2024 21:34, charliedidon...@gmail.com wrote:

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

Not sure if this is a Tomcat Config issue or Spring MVC 6 issue

I am converting from Spring MVC 4 to 6 and have the following set up in
Tomcat 10.1

  


Context.xml

 
url="jdbc:mysql://192.168.0.28:3306/reference_tables?allowPublicKeyRetrieval

=true&useSSL=false&autoReconnect=true&"/>


That looks reasonable.


Server.xml

   



 

 


This resource link is unnecessary and may be causing problems. Resource 
links are used in context.xml to expose resources defined in server.xml 
to the web application. You have defined the resource directly in the 
web application so there is no need for a resource link.





ResourceLink name="jdbc/CodereaperDB"

 global="jdbc/CodereaperDB"

 auth="Container"

 type="javax.sql.DataSource" />

   



When I deploy my Spring MVC 6 app I get the following in the Tomcat logs



Enable debug logging for the JNDI lookup with:

org.apache.naming.level = ALL

in $CATALINA_BASE/conf/logging.properties

The full path to that DataSource should be:

java:comp/env/jdbc/CodereaperDB


Mark


  


Caused by: javax.naming.NameNotFoundException: Name [jdbc/jdbcCodereaperDB]
is not bound in this Context. Unable to find [jdbc].

 at
org.apache.naming.NamingContext.lookup(NamingContext.java:520)

 at
org.apache.naming.NamingContext.lookup(NamingContext.java:155)

 at
org.apache.naming.SelectorContext.lookup(SelectorContext.java:144)

 at
java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)

 at
org.springframework.jndi.JndiTemplate.lambda$lookup$0(JndiTemplate.java:157)

 at
org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:92)

 at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:157)

 at
org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)

 at
org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:9
6)

 at
org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:114
)

 at
org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObject
FactoryBean.java:239)

 at
org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObject
FactoryBean.java:225)

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1853)

 at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory
.initializeBean(AbstractAutowireCapableBeanFactory.java:1802)

 ... 88 more

Related cause:

 org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'dataSource' defined in class path resource
[atlas-dao-context.xml]: Name [jdbc/jdbcCodereaperDB] is not bound in this
Context. Unable to find [jdbc].

  


Should I still be using javax.sql.DataSource or should I use something else
in the Jakarta packages??

My Spring bean is below

 

 



  

  





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: How to resolve 403 forbidden error in Tomcat level

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

based on the file "authenticationmethod.docx" there is a context param which 
set the authentication method to the value 0.
The context param is not used by tomcat but by the application.
So, the application seems to take care of authentication and authorization.
0 which stands for "ssa fm security authentication" according to the comment is 
not something, which tomcat provides.

I would suggest contacting the developer(s) or the supplier first to get deeper 
insights about the issue.

Greetings,
Thomas


> -Ursprüngliche Nachricht-
> Von: Rob Sargent 
> Gesendet: Donnerstag, 5. September 2024 04:36
> An: users@tomcat.apache.org
> Betreff: Re: How to resolve 403 forbidden error in Tomcat level
> 
> 
> 
> 
> On 9/3/24 11:22, Christopher Schultz wrote:
> > Jagadish,
> >
> > On 8/30/24 10:52, jagadish sahu wrote:> Please find the attached text
> > screenshot as you requested.
> >
> > Okay, I'm going to be perfectly honest: I'm not going to download and
> > read all those attachments. That's why I asked for plain-text.
> >
> > If someone else is willing to go through all that, feel free.
> >
> > I'm not going to go through a bunch of effort to provide free support.
> >
> > -chris
> Jagadish,
> Chris actually will 'go through a bunch of effort', but not extraneous.
> user-inflicted, unnecessary effort.
> 
> rjs
> >
> >> On Fri, Aug 30, 2024 at 3:37 AM Christopher Schultz
> >> mailto:ch...@christopherschultz.net>>
> >> wrote:
> >>
> >>     Jadgish,
> >>
> >>     This list does not accept image attachments. We are not seeing
> >> what you
> >>     are posting. Please post text-only.
> >>
> >>     -chris
> >>
> >>     On 8/29/24 11:01, jagadish sahu wrote:
> >>  > Hi Team and Christopher,
> >>  >
> >>  > We have attached a 403 error screenshot with full information.
> >>  > The error seems to be generated from Tomcat level.
> >>  >
> >>  > We don't have any changes in the java code and our application
> >> is
> >>  > working as expected in Tomcat 9.0.14.
> >>  >
> >>  > After upgrading to latest version Tomcat,we have been facing
> >> this
> >>  > issue(Error communicating with web server status:403)
> >>  >
> >>  > Please find attached screenshot for authentication and web.xml.
> >>  >
> >>  > It would be great help if you provide a solution for this.
> >>  >
> >>  > Thanks,
> >>  > Jagadish
> >>  >
> >>  >
> >>  >
> >>  > On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz
> >>  >  >>     <mailto:ch...@christopherschultz.net>
> >>     <mailto:ch...@christopherschultz.net
> >>     <mailto:ch...@christopherschultz.net>>> wrote:
> >>  >
> >>  >     Jagdesh,
> >>  >
> >>  >     On 8/29/24 06:29, jagadish sahu wrote:
> >>  >      > We have tested our application in Apache tomcat 9.0.14.
> >> It is
> >>  >     working as
> >>  >      > expected, After upgrading from 9.0.14 to the latest
> >>     versions it
> >>  >     is not
> >>  >      > working.
> >>  >      >
> >>  >      >    When we leave the session for 30 mins, we will get
> >> some
> >>  >     warning like
> >>  >      > due to an inactive session, you can click on Ok to
> >>     continue the
> >>  >     session,
> >>  >      > after clicking Ok we are getting a 403 error message
> >> (attached
> >>  >      > screenshot for your reference).
> >>  >
> >>  >     Your screenshot has been stripped from the list. Is this
> >> an
> >>  >     application-generated 403 or one from Tomcat?
> >>  >
> >>  >      > The correct functionality is it should not get any
> >> error
> >>     message,
> >>  >     after
> >>  >      > clicking waring message it should redirect to login
> >> page
> >>     again,
> >>  >     but in
> >>  >      > the latest version of tomcat 

Re: Migration of Spring MVC 4 app to Spring MVC 6

[Mark Thomas]

On 04/09/2024 00:33, charliedidon...@gmail.com wrote:

I am migrating a Spring MVC app from 4.x to 6.x so I am going from Tomcat
9.1 Java 8 to Tomcat 10.1 Java 17.

I noticed that in the migration steps on the Tomcat site that there is a
tool to help with the javax to Jakarta package conversions

  


I have downloaded the migration tool from Github
https://github.com/apache/tomcat-jakartaee-migration

I currently have 2 versions of Java on my machine.  Java 8 (Oracle) and Java
17 (Open JDK)

  


And am trying to build it and am getting the following error in Eclipse when
running maven verify.


Possibly an issue with the Eclipse environment?

mvn clean verify

works for me with both Java 8 and Java 17 with the current HEAD of the 
main branch.


I'd suggest building on the command line as a first step towards 
debugging what is going on.


Mark




It appears to be using my Java 8 JRE to run the maven build even though I
have JRE_HOME set to below

JRE_HOME=C:\Program Files\OpenLogic\jdk-17.0.12.7-hotspot

  


And my PATH has the Open JDK first in the PATH variable

Path=C:\Program Files\OpenLogic\jdk-17.0.12.7-hotspot\bin;C:\Program
Files\Microsoft\jdk-11.0.16.101-hotspot\bin;C:\Program
Files\Java\jre-1.8;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C
:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\P
rogram Files\Java\jre-1.8\bin;C:\Program Files\dotnet\;C:\Program Files
(x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program
Files\Amazon\AWSCLIV2\;C:\Program Files (x86)\Bitvise SSH Client;C:\Program
Files\MySQL\MySQL Shell
8.0\bin\;C:\Users\charlie\AppData\Local\Microsoft\WindowsApps;C:\Users\charl
ie\.dotnet\tools

  

  


Output from Maven verify is below

Not sure what to do about it

  


Scanning for projects...

[INFO]

[INFO] [1m---< [0;36morg.apache.tomcat:jakartaee-migration[0;1m

[m


[INFO] [1mBuilding Apache Tomcat Migration Tool for Jakarta EE
1.0.9-SNAPSHOT[m

[INFO]   from pom.xml

[INFO] [1m[ jar
]-[m

[INFO]
[1m[
m

[INFO] [1;31mBUILD FAILURE[m

[INFO]
[1m[
m

[INFO] Total time:  0.647 s

[INFO] Finished at: 2024-09-03T19:27:17-04:00

[INFO]
[1m[
m

[ERROR] Failed to execute goal on project [36mjakartaee-migration[m:
[1;31mCould not resolve dependencies for project
org.apache.tomcat:jakartaee-migration:jar:1.0.9-SNAPSHOT: The following
artifacts could not be resolved: com.sun:tools:jar:1.8.0: Could not find
artifact com.sun:tools:jar:1.8.0 at specified path C:\Program
Files\Java\jre-1.8/../lib/tools.jar[m -> [1m[Help 1][m

[ERROR]

[ERROR] To see the full stack trace of the errors, re-run Maven with the
[1m-e[m switch.

[ERROR] Re-run Maven using the [1m-X[m switch to enable full debug logging.

[ERROR]

[ERROR] For more information about the errors and possible solutions, please
read the following articles:

[ERROR] [1m[Help 1][m
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionExcepti
on

  

  





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0.93 Patching | Error- A fatal error has been detected by the Java Runtime Environment | Problematic frame:sigar-amd64-winnt.dll+0x14ed4

[Mark Thomas]

Not a Tomcat issue. You need to contact whoever provided the file:

C:\Program Files\Apache Software Foundation\Tomcat 
9.0\webapps\ROOT\WEB-INF\lib\sigar-amd64-winnt.dll


Mark


On 03/09/2024 08:33, Man Mohan wrote:

Hi Team,

Recently I was patching one of my Tomcat server from *9.0.88 to 
9.0.90/93* and then  we are getting below issue while starting the 
tomcat after the patching and it is generating mdmp file after each 
start and  after that services got stopped.


*OS: Window *

*JAVA: 1.8.421*

*Tomcat : 9.0.90/93* (both having issue)

Error:

# A fatal error has been detected by the Java Runtime Environment:

#

#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10014ed4, 
pid=7624, tid=0x0ad0


#

# JRE version: Java(TM) SE Runtime Environment (8.0_421) (build 
1.8.0_421-b09)


# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.421-b09 mixed mode 
windows-amd64 )


# Problematic frame:

*# C  [sigar-amd64-winnt.dll+0x14ed4]*

*#*

# Core dump written. Default location: C:\Program Files\Apache Software 
Foundation\Tomcat 9.0\hs_err_pid7624.mdmp


#

# If you would like to submit a bug report, please visit:

#   http://bugreport.java.com/bugreport/crash.jsp

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

Attached the full error file.

We have not patching before many time but we are facing this issue only 
this time , Requesting your help on this as this is stopping us to patch 
our environment with latest one.


Regards

Man Mohan



-
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: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify

[Mark Thomas]

On 29/08/2024 14:05, Christopher Schultz wrote:

Isaac,

On 8/26/24 13:24, Isaac Klickstein wrote:

What is the "Tomcat Native Client"?


I am using the Tomcat Native software (maybe "client" was wrong) 
available here to build the OpenSSLImplementation:

https://tomcat.apache.org/download-native.cgi#2.0.8

I then link to this library using LD_LIBRARY_PATH in the Tomcat's 
setenv.sh script.


Aah, okay. You are just using libtcnative on the server side. curl is 
the client.



How do you trigger this behavior? Just any request like "curl


I have been using the manager app, something like

curl --cacert  --url 'https://:https connector port>/manager/text/list' --user robot:robotpw


but any request to the ROOT/manager/other hosted would do.

I have been breaking down the behavior based on protocol=NIO/NIO2/APR 
and the sslImplementationName JSSE/OpenSSL


NIO/NIO2+JSSE = good
NIO/NIO2+OpenSSL = bad
APR+OpenSSL = good


That's interesting. When using APR+OpenSSL, the Tomcat code is entirely 
responsible for the connection management (e.g. socket, buffers, etc.) 
and the crypto (using OpenSSL, of course).


When using NIO+OpenSSL, Java is responsible for the connection 
management AND the orchestration of the use of the cryptographic module. 
The use of OpenSSL versus some other cryptographic module (e.g. built-in 
JSSE) should not affect whether a close_notify is sent. :/


I have TCP dumps for each of these configurations saved and could 
upload them as well as the configuration of the connectors.


Is a TCP dump required to observe this behavior, or will e.g. curl -vvv 
show it as well?


Is this causing any actual issues in your environment, or are you more 
reporting a spec violation that needs to be cleaned-up. It seems to be 
that if the client asks the server to close the connection, if the 
connection is closed then it's closed whether or not this particular 
message is transmitted before termination of the connection.


This should be fixed for the next round of releases.

Mark



-chris

On Monday, August 26th, 2024 at 11:40 AM, Christopher Schultz 
 wrote:



Isaac,

On 8/25/24 13:27, Isaac Klickstein wrote:


Hello Tomcat Users

Tomcat Version: 10.1.28
OpenSSL version: 3.0.14
Tomcat Native Client: 2.0.8



What is the "Tomcat Native Client"?

I have configured an HTTPS connector with the 
org.apache.coyote.http11.Http11NioProtocol protocol and the 
org.apache.tomcat.util.net.openssl.OpenSSLImplementation 
sslImplementationName using TLSv1.2


When I tcpdump any request to this connector, Tomcat is not 
returning a "close_notify" in response to a client's close_notify, 
and I cannot figure out how to force Tomcat to return a 
close_notify. This seems to be a violation of the TLS protocol which 
demands both sides issue a close_notify.



Careful: both the client and the server are always allowed to be
powered-off before they respond to any network stimulus. This is what
timeouts are for. TLS cannot place any more requirements on the network
peers than TCP has already done.

Recreating this situation, as far as I can tell, only requires 
combining the Http11NioProtocol with the OpenSSLImplementation 
(Tomcat9 or Tomcat10, TLSv1.2 or TLSv1.3, OpenSSL 3.0, 3.1, and 3.2, 
all exhibit this behavior).



How do you trigger this behavior? Just any request like "curl
https://example.com/"; ?

Other notes, switching the sslImplementationName to 
org.apache.tomcat.util.net.jsse.JSSEImplementation does return a 
close_notify by the server in response to the client's close_notify.


Also, switching back to Tomcat9, and using the 
org.apache.coyote.http11.Http11AprProtocol, Tomcat also returns a 
close_notify in response to a client's close_notify.


I have run out of ideas, googling this behavior has turned up 
nothing related to Tomcat (although there does appear to be a 
similar behavior noticed in Netty also using the OpenSSLEngine 
https://github.com/netty/netty/issues/6167)


Any help would be greatly appreciated, I am happy to send along any 
other information that would be informational for diagnostics



So...

Tomcat 10.1 + NIO/JSSE+OpenSSLImplementation+tcnative = bad
Tomcat 9.0 + APR+tcnative = good
Tomcat 9.0 + NIO/JSSE+OpenSSLImplementation+tcnative = ?

-chris

-
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



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail:

Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities

[Thomas Meyer]

Am 30. August 2024 16:20:24 MESZ schrieb Mark Thomas :
>On 30/08/2024 15:15, Kenan, John wrote:
>> Apache Tomcat Security Team:


Hi,

>> Please advise when an update to Apache Tomcat will be released that 
>> addresses the following Curl and libcurl security vulnerabilities:
>
>What makes you think Tomcat has a dependency on Curl and/or libcurl?

This kind of checkbox security is also implemented at my employer.

I assume a similar procedure is implemented here, and probably does involve a 
static code scanner of docker images and probably somehow disallows the deploy 
of images containing "critical" and/or "high" CVE finding...

@John: what docker image are you talking about? As far as I know Apache 
Foundation doesn't offer an official docker image.

>
>Mark
>
>
>> 
>> Critical:
>> CVE-2023-38545
>> 
>> High:
>> CVE-2024-7264
>> 
>> Medium:
>> CVE-2023-46218
>> CVE-2023-46219
>> CVE-2024-0853
>> 
>> Low:
>> CVE-2023-38546
>> 
>> Thank you,
>> 
>> John P. Kenan
>> DevSecOps Engineer
>> US Environmental Protection Agency
>> 
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities

[Mark Thomas]

On 30/08/2024 15:15, Kenan, John wrote:

Apache Tomcat Security Team:

Please advise when an update to Apache Tomcat will be released that addresses 
the following Curl and libcurl security vulnerabilities:


What makes you think Tomcat has a dependency on Curl and/or libcurl?

Mark




Critical:
CVE-2023-38545

High:
CVE-2024-7264

Medium:
CVE-2023-46218
CVE-2023-46219
CVE-2024-0853

Low:
CVE-2023-38546

Thank you,

John P. Kenan
DevSecOps Engineer
US Environmental Protection Agency



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Understanding ResorceLink property inheritance

[Mark Thomas]

On 29/08/2024 15:52, Marcelo de Sena Lacerda wrote:

The resource definition in server.xml

...
   
...
 


OK. The global resource looks good.


...


   *
Wrong factory.
   *
driverClassName is not a valid attribute for a ResourceLink
   *
url is not a valid attribute for a ResourceLink

 From reading the documentation that was also my initial thought, however if I 
write my ResourceLink like this:





The factory should be org.apache.naming.factory.DataSourceLinkFactory in 
the ResoucreLink. Otherwise the above looks OK to me.


(Note: I'm basing this off reading the documentation - I haven't tested 
that it actually works).


Mark




I get the following error:

javax.naming.NamingException: Unexpected exception resolving reference [Root 
exception is java.sql.SQLException: The url cannot be null

When my code tries to obtain the DataSource from the context:

DataSource ds = (DataSource)envContext.lookup("jdbc/mydatabase");
____
De: Mark Thomas 
Enviado: quinta-feira, 29 de agosto de 2024 10:30
Para: users@tomcat.apache.org 
Assunto: Re: Understanding ResorceLink property inheritance

On 29/08/2024 14:19, Marcelo de Sena Lacerda wrote:

Understanding ResorceLink property inheritance

My scenario is this, I have several applications running on a tomcat, all of 
them access the same database I want them to be inside the same pool so the 
number of connections oppened can be sensibly managed using the same 
parameters. All of that works as of now.

Additionally I also want them to connect to the database using different users 
so that's easier to identify which application is running which processes in 
the database.

My understanding is that I could do that with setting a Resource in my 
server.xml with all the pool configuration parameters set and a ResourceLink in 
the context.xml of the application with only the username and password set.


Yes, but only under specific circumstances.

https://tomcat.apache.org/tomcat-11.0-doc/config/context.html#Resource_Links


That more or less works. Indeed if setup the scenario described in the above paragraph I can set a 
different username and password for the Resource in the  ResourceLink, however it seems that tomcat 
"forgets" every other parameter of the Resource driverClass,url, and, more importantly 
maxActive, maxIdle, initialSize all gets "forgotten" by tomcat.

Why is that happening?


We need to see the resource definition in server.xml as there may be
changes required there as well.


I'm using tomcat 10.1.28 with java 22.0.2 from openjdk.

This is the ResourceLink that inherits all parameters from server.xml:



And this is one that forgets all parent parameters:




Wrong factory.
driverClassName is not a valid attribute for a ResourceLink
url is not a valid attribute for a ResourceLink

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

AW: How to resolve 403 forbidden error in Tomcat level

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Jagadish,

> Von: jagadish sahu  
> Gesendet: Donnerstag, 29. August 2024 17:02
> An: Tomcat Users List ; Christopher Schultz 
> 
> Betreff: Re: How to resolve 403 forbidden error in Tomcat level
>
> Hi Team and Christopher,
>
> We have attached a 403 error screenshot with full information.
> The error seems to be generated from Tomcat level.
>
> We don't have any changes in the java code and our application is working as 
> expected in Tomcat 9.0.14.
>
> After upgrading to latest version Tomcat,we have been facing this issue(Error 
> communicating with web server status:403)
>
> Please find attached screenshot for authentication and web.xml.
>
> It would be great help if you provide a solution for this.
>
> Thanks,
> Jagadish

Without internal information how the application works it is probably hard to 
tell.
Can you use the developer console (F12) and track the requests?
Which Urls are called, and which responses do you get?

How does the web.xml look like regarding authentication as Chris requested?


> On Thu, Aug 29, 2024 at 6:30 PM Christopher Schultz 
>  wrote:
> Jagdesh,

> On 8/29/24 06:29, jagadish sahu wrote:
> > We have tested our application in Apache tomcat 9.0.14. It is working as 
> > expected, After upgrading from 9.0.14 to the latest versions it is not 
> > working.
> > 
> >    When we leave the session for 30 mins, we will get some warning like 
> > due to an inactive session, you can click on Ok to continue the session, 
> > after clicking Ok we are getting a 403 error message (attached 
> > screenshot for your reference).
>
> Your screenshot has been stripped from the list. Is this an 
> application-generated 403 or one from Tomcat?
>
> > The correct functionality is it should not get any error message, after 
> > clicking waring message it should redirect to login page again, but in 
> > the latest version of tomcat its not working, so we are contacting you 
> > people.
> > 
> > Please provide a solution/ workaround for this issue.
>
> What kind of authentication are you using? What kind of login mechanism 
> are you using -- e.g. FORM versus HTTP BASIC/DIGEST, etc.?
>
> Can you post the relevant parts of your web.xml?
>
> -chris
>
> -
> To unsubscribe, e-mail: mailto:users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: mailto:users-h...@tomcat.apache.org

Re: Suggestion: Maven repository for Tomcat native library

[Mark Thomas]

On 27/08/2024 18:41, Mark Thomas wrote:

Please open a Bugzilla issue for this request so that it does not get lost.


https://bz.apache.org/bugzilla/show_bug.cgi?id=69299

Mark


On 09/08/2024 10:56, Harri Pesonen wrote:
Hello, currently Tomcat native library needs to be downloaded manually 
from here:


https://tomcat.apache.org/download-native.cgi

It would be better to download it from Maven repository, so that we 
could upgrade the version easier using Maven scripts.

Also we could see easier when the version needs to be upgraded.
Normally Maven repository contains only Java artifacts, but it is 
possible to upload binaries as well.
For example Microsoft JDBC driver has Java .jar in on artifact, and 
native .dll in separate artifact:


https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64

What say you?

-Harri



-
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: mod_jk retry continuing existing stream?

[Mark Thomas]

On 12/08/2024 19:54, Holle, Jess wrote:

I have mod_jk load balancing over several back-end Java processes which embed 
Tomcat.

When I Ctrl-C one of those processes, a server-sent-event response stream 
(which has already sent a number of events) does not end from a client 
perspective.  Rather the original request is retried against the next server 
and its response is simply added to the original stream from the client's 
perspective.

That is just plain weird - and doesn't make sense to me at all in terms of 
retry handling.


What have you got set for recovery_options on those workers?

If it is the default 0, you probably want to set it to 2.

I see what you mean in term so of the default behaviour being weird. I 
can see how the default makes sense for relatively quick GET requests. 
SSE is different. Hopefully, switching to 2 from the default should fix it.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Understanding ResorceLink property inheritance

[Mark Thomas]

On 29/08/2024 14:19, Marcelo de Sena Lacerda wrote:

Understanding ResorceLink property inheritance

My scenario is this, I have several applications running on a tomcat, all of 
them access the same database I want them to be inside the same pool so the 
number of connections oppened can be sensibly managed using the same 
parameters. All of that works as of now.

Additionally I also want them to connect to the database using different users 
so that's easier to identify which application is running which processes in 
the database.

My understanding is that I could do that with setting a Resource in my 
server.xml with all the pool configuration parameters set and a ResourceLink in 
the context.xml of the application with only the username and password set.


Yes, but only under specific circumstances.

https://tomcat.apache.org/tomcat-11.0-doc/config/context.html#Resource_Links


That more or less works. Indeed if setup the scenario described in the above paragraph I can set a 
different username and password for the Resource in the  ResourceLink, however it seems that tomcat 
"forgets" every other parameter of the Resource driverClass,url, and, more importantly 
maxActive, maxIdle, initialSize all gets "forgotten" by tomcat.

Why is that happening?


We need to see the resource definition in server.xml as there may be 
changes required there as well.



I'm using tomcat 10.1.28 with java 22.0.2 from openjdk.

This is the ResourceLink that inherits all parameters from server.xml:



And this is one that forgets all parent parameters:




Wrong factory.
driverClassName is not a valid attribute for a ResourceLink
url is not a valid attribute for a ResourceLink

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat takes over 1 minute to stop

[Mark Thomas]

On 27/08/2024 21:41, Christopher Schultz wrote:

Quoc,

On 8/27/24 14:58, Quoc Nguyen wrote:

Apache Tomcat version: 9.0.90 and above
OS: Windows Server 2019

Tomcat Version Used    Time Taken to stop

Apache Tomcat/8.5.66    ~ 9 seconds
Apache Tomcat/9.0.1    ~ 9 seconds
Apache Tomcat/9.0.10    ~ 9 seconds
Apache Tomcat/9.0.13    ~ 9 seconds
Apache Tomcat/9.0.14    ~ 1 min 3 secs
Apache Tomcat/9.0.16    ~ 1 min 3 secs
Apache Tomcat/9.0.20    ~ 1 min 3 secs
Apache Tomcat/9.0.30    ~ 1 min 3 secs
Apache Tomcat/9.0.40    ~ 1 min 3 secs
Apache Tomcat/9.0.44    ~ 1 min 3 secs
Apache Tomcat/9.0.46    ~ 1 min 3 secs
Apache Tomcat/9.0.75    ~ 1 min 3 secs
Apache Tomcat/9.0.89    ~ 1 min 3 secs
Apache Tomcat/9.0.90    ~ 1 min 3 secs
Apache Tomcat/9.0.93    ~ 1 min 3 secs

 From Tomcat changelog 
(https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.14_(markt): Version 9.0.14 "Add a scheduled executor to the Server, which can be used to process periodic utility tasks. The utility threads are non daemon by default. (remm)", which has the default timeout of 60s for procrun.


Workaround: to reduce the default timeout of 60s, I can supply it via 
Tomcat Monitor (Tomcat9w.exe) or while creating the Windows service.


This workaround has worked up to version 9.0.89 and has stopped for 
version 9.0.90 and above. The difference is version 9.0.89 and lower 
uses Apache Commons Daemon procrun (1.3.x.0 64-bit)  whereas version 
9.0.90 and above uses Apache Commons Daemon procrun (1.4.0.0 64-bit).


Questions:

1) Am I on the right rack with this procrun timeout?


No.



2) If #1 is yes, does the upgrade from Apache Commons Daemon procrun 
(1.3.x.0 64-bit) to Apache Commons Daemon procrun (1.4.0.0 64-bit) 
cause the supplied timeout to be ignored so that the default of 60s is 
always in effect?


2) If #2 is yes, is there a workaround while waiting for a fix or must 
wait for a fix?


Since this symptom lasts for more than a minute and (I assume) is 
trivially reproducible, you should take a thread dump to find out what 
Tomcat is doing during that time.


It is unlikely to be Tomcat. A clean Tomcat 9.0.93 install stops in 
around 1 second. It will be something the application is doing. Probably 
with a non-daemon thread or maybe a long running request.


+1 to the thread dump suggestion.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.

[Mark Thomas]

You can try copying tomcat-jdbc.jar from 9.0.91. It should work but you 
are on your own if you try it and it doesn't.


Mark


On 28/08/2024 21:47, Mcalexander, Jon J. wrote:

Ok, so should we stop pushing 9.0.93 until 9.0.94? Is there a temporary 
work-around, like put the 9.0.91 commons-daemon.jar or other jar in the 
CATALINA_BASE lib folder?

Thanks,

From: Chuck Caldarale 
Sent: Wednesday, August 28, 2024 3:36 PM
To: Tomcat Users List 
Subject: Re: Tomcat 9.0.93 and java.sql.SQLException: ResultSet closed.


On Aug 28, 2024, at 15: 16, Mcalexander, Jon J.  wrote: > > We upgraded a number of non-production servers starting last 
night to Tomcat 9. 0. 93 from 9. 0. 91. We are now receiving complaints






On Aug 28, 2024, at 15:16, Mcalexander, Jon J. 
mailto:jonmcalexan...@wellsfargo.com.INVALID>>
 wrote:







We upgraded a number of non-production servers starting last night to Tomcat 
9.0.93 from 9.0.91. We are now receiving complaints from application teams with 
issues around: java.sql.SQLException: ResultSet closed.






This should be fixed in the next round of releases.



https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?id=69279__;!!F9svGWnIaVPGSwU!pzpi_V5tNrGx4kVdFx8EnL2_qGX2v9DB_Z37wp-ACBuIEO7nwHsMOWX-nnsgjZuxbZNZnWukYgc7mKetKmhyCw$



   - Chuck






Here are some stack-traces.







1.







024-08-28 04:01:37,081 [gaRULES-ShutDownTask] [  STANDARD] [
] [] (l.access.RDBPageResultPackager) ERROR- Problem 
getting database results



com.pega.pegarules.pub.database.ConnectionException: Database-General   Problem 
processing list results 0   ResultSet closed.



DatabaseException caused by prior exception: java.sql.SQLException: ResultSet 
closed.



| SQL Code: 0 | SQL State: null















at 
com.pega.pegarules.data.internal.access.ExceptionInformation.createAppropriateExceptionDueToDBFailure(ExceptionInformation.java:379)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.ExceptionInformation.createExceptionDueToDBFailure(ExceptionInformation.java:364)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageDataStoreResults(RDBPageResultPackager.java:439)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.RDBPageResultPackager.packageResults(RDBPageResultPackager.java:462)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.Lister.listWithResultPackager(Lister.java:426)
 ~[prprivate-data.jar:?]



at com.pega.pegarules.data.internal.access.Lister.list(Lister.java:196) 
~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:126)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DBQueryExecutor.executeRDB(DBQueryExecutor.java:73)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3234)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.data.internal.access.DatabaseImpl.executeRDB(DatabaseImpl.java:3214)
 ~[prprivate-data.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.deleteUsageDetails(RuleUsageImpl.java:464)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:278)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl$1.run(RuleUsageImpl.java:382)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1381)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1124)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:931)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:897)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.monitor.internal.context.RuleUsageImpl.updateSnapshot(RuleUsageImpl.java:380)
 ~[prprivate-monitor.jar:?]



at 
com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.RuleUsageSnapshotTask.exec(RuleUsageSnapshotTask.java:41)
 ~[prprivate-session.jar:?]



at 
com.pega.pegarules.session.internal.engineinterface.shutdown.shutdowntasks.IParallelShutdownTask.run(IParallelShutdownTask.java:43)
 ~[prprivate-session.jar:?]



at 
java.util.concurrent.Executors$RunnableA

Re: How to resolve 403 forbidden error in Tomcat level

[Mark Thomas]

http://www.catb.org/~esr/faqs/smart-questions.html

On 28/08/2024 17:02, jagadish sahu wrote:

Hi Team,

I am getting an error 403 forbidden error in my application. I want to fix
errors in Tomcat level.
Anything I need to change in tomcat level.

  I am using tomcat 9.0.91.

Thank you
Jagadish



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Suggestion: Maven repository for Tomcat native library

[Mark Thomas]

Please open a Bugzilla issue for this request so that it does not get lost.

Mark

On 09/08/2024 10:56, Harri Pesonen wrote:

Hello, currently Tomcat native library needs to be downloaded manually from 
here:

https://tomcat.apache.org/download-native.cgi

It would be better to download it from Maven repository, so that we could 
upgrade the version easier using Maven scripts.
Also we could see easier when the version needs to be upgraded.
Normally Maven repository contains only Java artifacts, but it is possible to 
upload binaries as well.
For example Microsoft JDBC driver has Java .jar in on artifact, and native .dll 
in separate artifact:

https://mvnrepository.com/artifact/com.microsoft.sqlserver/mssql-jdbc_auth/12.8.0.x64

What say you?

-Harri



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Ignoring invalid If-None-Match header instead of status 400?

[Mark Thomas]

On 22/08/2024 14:29, Jiřička, Martin wrote:

Hi,

I was investigating an issue with our single-page app that is using
Tomcat on server side. The app sometimes did not load in browser. It
turned out Chrome can requests client application bundle with header
like this:

If-None-Match: W/"101052-1724152266000"-gzip

Default servlet rejects such request with HTTP Status 400 – Bad Request.

To test it I installed Tomcat 9.0.93 and queried default ROOT application:

$ curl -sw '%{http_code}\n' --output /dev/null -H 'If-None-Match:
W/"101052-1724152266000"-gzip' localhost:8080/tomcat.css
400

Problematic part is "-gzip", without it it works:

$ curl -sw '%{http_code}\n' --output /dev/null -H 'If-None-Match:
W/"101052-1724152266000"' localhost:8080/tomcat.css
200

I have no idea whether the header is RFC-valid or not,


It isn't. From RFC 9110:

13.1.2
  If-None-Match = "*" / #entity-tag

8.8.3
  entity-tag = [ weak ] opaque-tag
  weak   = %s"W/"
  opaque-tag = DQUOTE *etagc DQUOTE
  etagc  = %x21 / %x23-7E / obs-text
 ; VCHAR except double quotes, plus obs-text

The -gzip should be inside the double quotes.


but since it is
used by major browser/s and status 400 can break things, is there some
option how to silently ignore invalid(?) If-None-Match?


Sorry, no.

It might be worth tracking down what is generating the invalid ETag. It 
is possible that the browser is just echoing back an invalid ETag it 
originally received.


Whether the browser should accept and/or echo an invalid ETag is 
arguable. I suspect it does so for interoperability reasons.


I've done a quick check of the Tomcat source and I don't think it is 
Tomcat that is generating that ETag.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: j_security_check error

[Mark Thomas]

On 16/08/2024 16:16, Fernando wrote:

Hi all,
I need help with problem that I can't fix.
I am using Apache Tomee 8, but I know that Apache Tomee rest on Apache
Tomcat, in this case version 9.
My problem is when some user exit from application this forward to login
page doing this:
HttpSession session = request.getSession();
session.invalidate();

request.getRequestDispatcher("/login.jsp").forward(request, response);

then if same user try to login, this launch something like this:
   http://localhost:8080/appweb/privado/j_security_check

Asking in other forums, I read  that " when you use JEE-standard Container
security, the user should not explicitly request the login/loginfail pages.
It won't work right."


That is correct. Some implementations have additional configuration 
options so this doesn't break but you would be better forwarding to a 
default page that requires authentication. The FORM auth will do its thing.



However I have other applicacion running on payara and that works, then I
start to think that maybe is something misconfigured...
Someone has some idea about this problem?


https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Form_Authenticator_Valve/Attributes

Look for "landingPage"

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Bypassing Ldap in tomcat .

[Mark Thomas]

On 16/08/2024 03:53, Shekhar Dhotre wrote:

Hello Expert ,
Which is the configuration file wheee we can tell tomcat to bypass Ldap 
authentication and log in directly to oracle ?


Oracle what? Database?

Probably one of:
- $CATALINA_BASE/conf/server.xml
- $CATALINA_BASE/conf/context.xml
- $CATALINA_BASE/conf///.xml
- $CATALINA_BASE/webapps//META-INF/context.xml
- $CATALINA_BASE/webapps/.war!/META-INF/context.xml

If all else fails

grep -R oracle *

or the server name, IP address, database name, user name etc


We have IBM ldap whose password is not known so failing on authentication .


So reset the password.

And I assume the answer to your first question is "Wherever you are 
trying to set the password in your second question".


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Web browser clocking issue at Apache Tomcat 10.1.20 on Linux

[Mark Thomas]

On 15/08/2024 14:36, Tim Zielke wrote:




web browser clocking issues




Can you clarify what you mean by this please.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring

[Mark Thomas]

On 14/08/2024 17:10, Itzhak Fadida wrote:

Thank you very much for quickly addressing the issue!
When do you estimate it will be part of a release?


It will be included in the September release round.

Mark




From: Mark Thomas 
Date: Wednesday, 14 August 2024 at 11:56
To: users@tomcat.apache.org 
Subject: Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 
with Spring
On 13/08/2024 17:53, Mark Thomas wrote:

On 13/08/2024 09:48, Itzhak Fadida wrote:

Thank you for your reply. I created a repository that demonstrates the
issue.

https://github.com/tzahifadida/test-chunked


Thanks. That is very helpful.

git bisect has identified this commit:

https://github.com/apache/tomcat/commit/92e3c7a7adc574a859ab70333bf930561dcf1e9d

as the cause of the change in behaviour.

That makes sense as it is a change to the processing of chunked requests.

I need to debug this further to figure out what and where the root cause
is.


Found it. The root cause was in Tomcat. The CRLF terminating a chunk of
the request body wasn't accounted for when determining if there was more
data to read. This caused the decoder to continue to try and read when
there was no data. This in turn caused the decoder to wait until the
next line arrived (and the next line, and the next line) before
returning causing the whole body at once.

I've written a test case based on your test project and confirmed that
the proposed fix addresses the issue.

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: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring

[Mark Thomas]

On 13/08/2024 17:53, Mark Thomas wrote:

On 13/08/2024 09:48, Itzhak Fadida wrote:
Thank you for your reply. I created a repository that demonstrates the 
issue.


https://github.com/tzahifadida/test-chunked


Thanks. That is very helpful.

git bisect has identified this commit:

https://github.com/apache/tomcat/commit/92e3c7a7adc574a859ab70333bf930561dcf1e9d

as the cause of the change in behaviour.

That makes sense as it is a change to the processing of chunked requests.

I need to debug this further to figure out what and where the root cause 
is.


Found it. The root cause was in Tomcat. The CRLF terminating a chunk of 
the request body wasn't accounted for when determining if there was more 
data to read. This caused the decoder to continue to try and read when 
there was no data. This in turn caused the decoder to wait until the 
next line arrived (and the next line, and the next line) before 
returning causing the whole body at once.


I've written a test case based on your test project and confirmed that 
the proposed fix addresses the issue.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring

[Mark Thomas]

On 13/08/2024 09:48, Itzhak Fadida wrote:

Thank you for your reply. I created a repository that demonstrates the issue.

https://github.com/tzahifadida/test-chunked


Thanks. That is very helpful.

git bisect has identified this commit:

https://github.com/apache/tomcat/commit/92e3c7a7adc574a859ab70333bf930561dcf1e9d

as the cause of the change in behaviour.

That makes sense as it is a change to the processing of chunked requests.

I need to debug this further to figure out what and where the root cause is.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat Connectors 1.2.50 released

[Mark Thomas]

The Apache Tomcat Connectors project is part of the Tomcat project and
provides web server plugins for httpd (mod_jk) and IIS (ISAPI) to 
connect those web servers with Tomcat and other backends.


The Apache Tomcat Project is proud to announce the release of version
1.2.50 of the Apache Tomcat Connectors.
This version fixes a number of bugs found in previous releases.

Full details of these changes and new features,
are available in the Apache Tomcat Connectors changelog:
https://tomcat.apache.org/connectors-doc/miscellaneous/changelog.html

In addition to the usual source release, this release includes Windows
binaries for the JK ISAPI connector for IIS.

Downloads:
https://tomcat.apache.org/download-connectors.cgi

Thank you,
--
The Apache Tomcat Team

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with Chunked Transfer Encoding in Tomcat 10.1.25-10.1.28 with Spring

[Mark Thomas]

On 11/08/2024 13:50, Itzhak Fadida wrote:

• Problem: Chunked transfer encoding seems to behave incorrectly in
Tomcat versions 10.1.25 through 10.1.28. Specifically, instead of
receiving several chunks of data, I am receiving the entire message in
a single chunk, but only when the connection is closed by the client.


What makes multiple chunks correct and one chunk incorrect?

If the connection is closed by the client, how is the client receiving 
the response?



I reviewed the changelogs and noticed there were modifications related
to chunked transfer encoding in these versions.


Really? What changes?


• Spring Version: 3.3.2.


Do you mean Spring Boot here?


I appreciate any insights or advice from the community. If additional
information is needed, I’m happy to provide it.


A minimal reproducible test case is usually the easiest way for other 
folks to investigate the behaviour you are seeing.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL

[Mark Thomas]

On 09/08/2024 09:28, Patil, Tushar wrote:

Hi Tomcat team,
Earlier in the 9.x.x series, the pipe(|) character was allowed with the AJP 
connector without doing any configuration change at our end, but now in 
10.1.23, it is giving an error.
Is this bug from the Tomcat side, or do we need any configuration changes at 
our end?


This is an application bug at your end. '|' is not a valid character in 
a URL. It has to be %nn encoded if you want to use it.


Mark





--
Thanks and Regards,
Tushar Patil

From: Christopher Schultz 
Sent: Thursday, August 8, 2024 11:51 PM
To: users@tomcat.apache.org 
Subject: Re: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for 
pipe characters in URL

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Chuck,

On 8/8/24 09:58, Chuck Caldarale wrote:



On Aug 8, 2024, at 08:46, Christopher Schultz  
wrote:

On 8/8/24 05:20, Patil, Tushar wrote:

In older version [9.0.82]:
  
In newer version[10.1.23]:



IMPORTANT NOTE: You have posted your "requiredSecret" value and may want to 
change that now that it is public.

I'm not sure why you would not have needed these in the past, but you might need to add 
relaxedPathChars="|" in your  configuration to allow these pipes.

If the pipes are also appearing in your query string, you may need to set 
relaxedQueryChars to the same value.



The AJP connector documentation does not show relaxedPathChars nor 
relaxedQueryChars as valid configuration items - these are only in the HTTP/1.1 
connector. I thought that the AJP connector expected the front end to do URL 
validation.


+1

I hadn't noticed the AJP in there until after I had written most of the
reply, then went back to add info about the secret and reverse proxy. Oops.

-chris

-
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: Upgraded Tomcat 9.0.82 to 10.1.23 getting HTTP response 400 for pipe characters in URL

[Mark Thomas]

On 08/08/2024 14:58, Chuck Caldarale wrote:



On Aug 8, 2024, at 08:46, Christopher Schultz  
wrote:

On 8/8/24 05:20, Patil, Tushar wrote:

In older version [9.0.82]:
 
In newer version[10.1.23]:



IMPORTANT NOTE: You have posted your "requiredSecret" value and may want to 
change that now that it is public.

I'm not sure why you would not have needed these in the past, but you might need to add 
relaxedPathChars="|" in your  configuration to allow these pipes.

If the pipes are also appearing in your query string, you may need to set 
relaxedQueryChars to the same value.



The AJP connector documentation does not show relaxedPathChars nor 
relaxedQueryChars as valid configuration items - these are only in the HTTP/1.1 
connector. I thought that the AJP connector expected the front end to do URL 
validation.


It does. I suspect the reverse proxy was updated when Tomcat was updated.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Reg: tomcat CPU spikes

[Mark Thomas]

On 08/08/2024 15:03, Jalaj Asher wrote:

HI Mark/Chris,
I wanted to check if you could review the below template and see if you have 
any suggestions on the syntax
I did try a lot of different options but none of them worked. >
Below is another example




That won't work.

CacheStrategy is an interface. You have to implement the interface. 
Chris provided you with a partial example earlier in this thread.





@Override

public boolean noCache(String path) {
  return !path.endsWith(".jar");
}


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Apache Tomcat Memory Allocation

[Mark Thomas]

On 08/08/2024 10:40, Sagar Palle wrote:

Hi,

I have installed the tomcat version *tomcat-9.0.84 *in the window 
system, it is consuming 29GB memory, and we configure the memory in the 
catalina.bat(C:\tomcat-9.0.84\bin) 24GB, it is still consuming the 
29GB memory.


That is entirely expected.

"Maximum Java Heap Space" < "Maximum Memory used by Java Process"


*OS Details:*


This mailing lists drops images. Use plain text.

Can you please suggest where we need to configure the  memory for the 
Apache tomcat service.


You should not edit catalina.bat. Use setenv.bat.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Upgraded tomcat 9.0.82 to 10.1.23 getting HTTP resonse 400 for pipe charactets in URL

[Mark Thomas]

On 08/08/2024 08:19, Patil, Tushar wrote:

Hi Team,

After upgrading Apache Tomcat from 9.0.82 to 10.1.23, we started getting HTTP 
response 400 if the URL contains a pipe(|) character.

According to the reference provided below, Apache made some related changes, 
but these were implemented in versions 8.5.6 and earlier. Currently, we are not 
able to figure out why we started getting this problem in 10.1.23.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1397484

Please help us to figure out the reason for the same.


Please provide the HTTP connector settings you used with both Tomcat 
versions.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat deploying war file for every restart on Red Hat Linux 8.6

[Mark Thomas]

On 08/08/2024 08:48, Channa Puchakayala wrote:

Hi All,

Any suggestions or help on this ?


What file system is being used? Is this a physical box or a VM? Is the 
storage local, NAS etc?



shall I create defect ?


Unless you can provide the steps to reproduce this issue on Ubuntu or 
another free OS (RHEL requires real money to test with) any such issue 
is likely to get resolved as WORKSFORME.


That no-one else is reporting this issue strongly suggests an 
environmental issue rather than a Tomcat bug.


Mark




Thanks

Channa

*From:* Channa Puchakayala >

*Sent:* Monday, August 5, 2024 1:29 PM
*To:* 'Tomcat Users List' >
*Cc:* 'Narayanarao Yenduri' >; 'Naga Naveen Chevendra' 
>; 'Balamurali Krishna Ippili' 
mailto:balamurali.ipp...@broadcom.com>>
*Subject:* RE: Tomcat deploying war file for every restart on Red Hat 
Linux 8.6


Hi Tomcat Team,

Thanks to all for helping on this.

- We set the "*autoDeploy="false*" *in server.xml* already, even though 
it is replaying war without any changes in war file


- Here main issue is, *war-tracker* file doesn't get the same modified 
date as the war file.


*@Chris,*

Please find the requested data below.

-As per above screenshot, it is clear that *war-tracker* file doesn't 
get the same modified date as the war file.


-We don’t have local compiled tomcat to print custom logs.

*Note:*

I tested this (ca-nim-sm.war) with my application “*Spectrum*” and also 
without my application, both cases result is same i.e. redeploying war 
for every restart, that is the reason log message  and screenshot 
showing different path in my previous mail.


Regards

Channa

-Original Message-
From: Christopher Schultz >

Sent: Saturday, August 3, 2024 12:00 AM
To: users@tomcat.apache.org 
Subject: Re: Tomcat deploying war file for every restart on Red Hat 
Linux 8.6


Channa,

On 8/2/24 05:30, Channa Puchakayala wrote:

 > Hi Tomcat Team,

 >

 > Issue : Apache Tomcat deploying war file for every restart on Red Hat

 > Linux 8.6 even though there are no changes in war file.

 >

 > Observations:

 >

 > -war-tracker file timestamp is setting with tomcat restart time which

 > is not matched with original war file timestamp, so tomcat deleting

 > existing ca-nim-sm folder and extracting war again for every restart.

 >

 > -Tomcat log message is below

 >

 > =

 >

 > Line 13640: 2024-07-26 06:41:46,035 [main] INFO

 >   org.apache.catalina.startup.ExpandWar - An expanded directory

 > [/usr/Spectrum/tomcat/webapps/*ca-nim-sm*] was found with a last

 > modified time that did not match the associated WAR. It will be deleted.

 >

 > 

 >

 > -server.xml setting (   unpackWARs="true" autoDeploy="false">)

 >

 > -We observed this for multiple web applications (wars) on multiple

 > systems, so it is not an issue single web application(war)

 >

 > -Issue observed in Red Hat Linux 8.6, but same not occurring on

 > windows box and Red Hat Linux 8.8, 8.9 and 8.10

 >

 > Please notice *ca-nim-sm.war* file  time stamp

 >

 > Please notice *war-tracker* file time stamp, which is set to tomcat

 > restart time

 >

 > Environment

 >

 > Red Hat Linux 8.6

 >

 > Java: OpenJDK 11.0.23 and 17.0.10

 >

 > Tomcat :  9.0.87 and 9.0.91

 >

 > Verified tomcat release notes and also tomcat defects in

 > https://bz.apache.org/bugzilla/  
>,


 > could not find any info/defect related to this.

 >

 > Could you please help us,  why war-tracker file timestamp getting

 > updated with tomcat restart time instead of keeping war file timestamp.

The code is fairly simple here in ExpandWar.java: the war-tracker file 
gets the last-modified date of the WAR file that was expanded, and 
shouldn't trigger a re-load after that unless either the WAR file or the 
war-tracker file's timestamps are modified.


Can you post the results of these commands?

$ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm.war

$ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm

$ stat /usr/Spectrum/tomcat/webapps/ca-nim-sm/META-INF/war-tracker

Please note that the log file shows the paths as being under 
/usr/Spectrum/tomcat/webapps/... while your screenshots show 
/usr/apache-tomcat-9.0.91/webapps/... are you sure you are looking in 
the right place(s) for these files and timestamps?


The next thing to do would be to add both timestamps to the log message 
to see what their values are. Perhaps revealing their values will give 
some insight into the root problem.


Are you able to compile your own Tomcat locally, or would you need a 
custom release artifact to try something like that?


-chris

-

[ANN] Apache Tomcat 11.0.0-M24 (beta) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M24 (beta).

Apache Tomcat 11 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 available to aid this process.

Apache Tomcat 11.0.0-M24 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.0-M22 include:

- Align HTTP/2 with HTTP/1.1 and recycle the container internal request
  and response processing objects by default. This behaviour can be
  controlled via the new discardRequestsAndResponses attribute on the
  HTTP/2 upgrade protocol.

- Add FFM compatibility methods for LibreSSL and BoringSSL support.

- Add support for RFC 8297 (Early Hints). Applications can use this
  feature by casting the HttpServletResponse to
  org.apache.catalina.connector.Reponse and then calling the method
  void sendEarlyHints()

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: AW: Problem getting logging from TldScanner

[Mark Thomas]

On 06/08/2024 09:39, Döscher, Andreas (ESI) wrote:

Hi Mark,
ah! Thanks! After I enabled

java.util.logging.ConsoleHandler.level = ALL

(and set the level to FINEST) I got the TLD messages I was missing.


FYI, it looks like we will switch those logs back to debug (FINE) but 
change the handler levels to ALL.


Thanks for bringing this to our attention.

Mark



Thanks,
   Andreas

-Ursprüngliche Nachricht-
Von: Mark Thomas 
Gesendet: Dienstag, 6. August 2024 09:58
An: users@tomcat.apache.org
Betreff: Re: Problem getting logging from TldScanner


WARNING: Do not click links or open attachments unless you recognize the source 
of the email and know the contents are safe.

On 05/08/2024 11:07, Döscher, Andreas (ESI) wrote:

Moin,
I wanted to check the TLD scanner and placed*

org.apache.jasper.servlet.TldScanner.level = FINE

in logging.properties, but under Tomcat 10.1.25 and Tomcat 9.0.91 I
get only

05-Aug-2024 10:43:29.958 INFO [main] 
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for 
TLDs yet contained no TLDs. Enable debug logging for this logger for a complete 
list of JARs that were scanned but no TLDs were found in them. Skipping 
unneeded JARs during scanning can improve startup time and JSP compilation time.





* Yes, I tried FINE, FINEST and ALL...


You need:

... = FINEST

but you also need to update the handlers as well since they filter out 
everything below FINE by default.

Now we have started using trace (aka FINEST) level logging we need to update 
that message and probably the default logging configuration.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, notify the sender immediately by return email and delete the message 
and any attachments from your system.

-
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: Problem getting logging from TldScanner

[Mark Thomas]

On 05/08/2024 11:07, Döscher, Andreas (ESI) wrote:

Moin,
I wanted to check the TLD scanner and placed*

org.apache.jasper.servlet.TldScanner.level = FINE

in logging.properties, but under Tomcat 10.1.25 and Tomcat 9.0.91 I get only

05-Aug-2024 10:43:29.958 INFO [main] 
org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for 
TLDs yet contained no TLDs. Enable debug logging for this logger for a complete 
list of JARs that were scanned but no TLDs were found in them. Skipping 
unneeded JARs during scanning can improve startup time and JSP compilation time.





* Yes, I tried FINE, FINEST and ALL...


You need:

... = FINEST

but you also need to update the handlers as well since they filter out 
everything below FINE by default.


Now we have started using trace (aka FINEST) level logging we need to 
update that message and probably the default logging configuration.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to initialize component [Connector["ajp-nio-127.0.0.1-8081"]]

[Mark Thomas]

On 01/08/2024 08:21, Neville Seed wrote:

Hello
I have a server running tomcat on several ports and connections. All other 
connections work as expected on this server and it has been working like this 
for a number of years.



The error I get is

INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["http-nio-8061"]
  INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["ajp-nio-127.0.0.1-8081"]
  SEVERE [main] org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to 
initialize component [Connector["ajp-nio-127.0.0.1-8081"]]
 org.apache.catalina.LifecycleException: Protocol handler 
initialization failed
 at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
 at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
 at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)
 at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
 at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039)
 at 
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:746)



[root@bcprdlnxreva01 conf]# netstat -tnal |grep 8081
tcp6   0  0 :::8081 :::*LISTEN
[root@bcprdlnxreva01 conf]# netstat -tnal |grep 8491
[root@bcprdlnxreva01 conf]#


In the server.xml file I have


 
 



do you have any suggestions as to the issue?


Something other than Tomcat is listening on port 8081 using ipv6.
Use "netstat -tnalp" to identify it.

If you want to limit AJP to ipv4, use address "127.0.0.1" rather than 
"localhost". That might work depending on your OS.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Jakarta EE 11 Release Delayed

[Mark Thomas]

On 30/07/2024 15:53, William Crowell wrote:

Good morning,

I received an update from the Jakarta EE Community mailing list this morning 
that the Jakarta EE 11 final release will be pushed out a quarter to deal with 
platform TCK migration to Arquillian/Junit 5. The exact target date is still 
TBD.

I am assuming this also pushes Apache Tomcat 11’s final release as well?


I don't see any reason for it to do that.

Tomact 11 milestones are already at beta meaning:

- the specifications Tomcat 11 implements have been released

- Tomcat fully implmements the specifications (and passes the Servlet,
  Pages, EL, WebSocket and Annotations TCKs)

My plan was to see how the August release went and - if things went well 
- start a discussion on the dev@ list about moving to stable releases 
for Tomcat 11.


In case by final release you meant EOL date, that will be driven by the 
release date for Tomcat 14 since we support 3 major releases in 
parallel. It is hard to predict that far in the future but past major 
Tomact releases have typically been support for ~10 years. At this point 
I dont see any reason why Tomcat 11 woudl be different.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Reg: tomcat CPU spikes

[Mark Thomas]

On 26/07/2024 22:19, Jalaj Asher wrote:

Thanks Christopher.
But can we also consider allowing caching of different types as caching jar 
files is very valuable as that avoids jar scans real time when the production 
is under load .

But trying to cache static content, which can be cached separately on client 
end, or jsps which are compiled and cached in work folder don’t need to be 
loaded in memory as they force a significant increase in memory utilization.


Sounds like you need to provide a custom 
org.apache.catalina.WebResourceRoot$CacheStrategy implementation.


See https://tomcat.apache.org/tomcat-11.0-doc/config/resources.html 
towards the end of the page and 
https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/catalina/WebResourceRoot.CacheStrategy.html


Mark




Regards

Jalaj P Asher

-Original Message-
From: Christopher Schultz 
Sent: Monday, July 22, 2024 12:35 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/19/24 14:28, Jalaj Asher wrote:

This is the warning message we get when cachingAllowed is not set to
false

org.apache.catalina.webresources.Cache.getResource Unable to add the resource 
at [/WEB-INF/classes/] to the cache for web application [/x] because there 
was insufficient free space available after evicting expired cache entries - 
consider increasing the maximum size of the cache.


Okay, I see it. Specifically, it is a WARN message which is usually not 
suppressed in a production configuration.

@markt @remm what do you think about making this another of those "WARN the first 
time, DEBUG thereafter" kinds of messages?

It seems like if a cache is full, the operator SHOULD get a notification, but 
if the cache is thrashing, printing an error a huge number of times doesn't 
seem like it's terribly helpful. It just fills the disk.

-chris


-Original Message-
From: Jalaj Asher
Sent: Tuesday, July 16, 2024 1:30 PM
To: Tomcat Users List 
Subject: RE: Reg: tomcat CPU spikes


space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.

1. Also interesting. Can you post one of those messages here? Was there a stack 
trace shown or just the warning?

  It is just the warning. No stack trace. I will work on recreating this 
since all our environments has this disabled.

2. Interesting. How much static content do you have? This seems like a good 
use-case for a reverse-proxy to handle your staticcontent for you.
We have not collated the complete size of it. But are reasons we cannot do that.

Also I was reviewing some older heap dumps and I could see that the jars are 
getting cached in tomcat even with cachingAllowed=false.

Also this is not a consistent issue once it happens it takes sometime for the 
stack to go away as well as post tomcat reboots the problem goes away with the 
same settings and we do see that the wars are getting deployed during tomcat 
startup as well.

Regards

Jalaj P Asher


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 16, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.

Interesting. How much static content do you have? This seems like a good 
use-case for a reverse-proxy to handle your static content for you.


2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.

Also interesting. Can you post one of those messages here? Was there a stack 
trace shown or just the warning?

-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleas

Re: Seeking clarification on ServletContext.createServlet() behavior post context initialization

[Mark Thomas]

Ryan,

I think you are in territory that is undefined by the Servlet 
specification and is likely to remain that way.


The expectation is that ServletContext.createServlet() is used followed 
by addServlet(String, Servlet) and addServlet(String, Servlet) can only 
be used before content initialisation is complete.


Further, the @ServletSecurity annotations apply when a request is mapped 
to the Servlet by the container - not when the Servlet methods are 
called directly.


From the general description of the functionality your tool is 
providing, I would expect it to be implemented as a Filter.


Mark


On 24/07/2024 23:13, Ryan Lubke wrote:

Hey Folks,

Tomcat version: 10.1.26
JDK:   "21.0.3" 2024-04-16 LTS
OS: Macos Sonoma 14.5

I'm looking for clarification on what annotations will be supported when
calling ServletContext.createServlet() after the context has been
initialized.

Some background; I have a tool that inspects a web application where for
each discovered Servlet (either declared in the {web,web-fragment}.xml or
via annotations) will wrap that Servlet which performs additional logic
during init and service before calling through to the actual delegate that
we wrapped.  When this wrapper's init() is first called by the container,
we will instantiate the delegate using ServletContext.createServlet().  The
Servlet 6.0 specification states the following:

-
4.4.1.5.  T createServlet(Class clazz)

This method instantiates the given Servlet class. The method must support
all the annotations applicable to servlets except @WebServlet. The returned
Servlet instance may be further customized before it is registered with the
ServletContext via a call to addServlet(String, Servlet) as defined above.
The given Servlet class must define a zero argument constructor, which is
used to instantiate it.
-

This works fine for cases such as @Inject or @Resource, however, I've found
the behavior in the case of @ServletSecurity to differ between containers.
For example, Tomcat, Jetty, and Wildlfy appear to ignore @ServletSecurity
when calling createServlet() from the wrappers init() method.

However, section 13.4.1 has the following constraint on @ServletSecurity:
-
When metadata-complete=true is defined for a portable deployment
descriptor, the @ServletSecurity annotation does not apply to any of the
url-patterns mapped to (any servlet mapped to) the annotated class in the
deployment descriptor.
-

In my test case, the descriptor containing the original Servlet has the
metadata-complete attribute set to true.  If I set it to false, I find that
the security constraints are applied, but only when running with Jetty;
Tomcat and Wildfly continue to ignore the desired constraints.

Going back to section 4.4 for a moment which states:
-
The following methods are provided on the ServletContext interface to
enable programmatic definition of servlets, filters and the url pattern(s)
that they map to. These methods can only be called during the
initialization of the application either from the contexInitialized method
of a ServletContextListener implementation or from the onStartup method of
a ServletContainerInitializer implementation.
--

The javadocs for ServletContext.createServlet() don't impose any
restrictions on when it may be called unlike the javadocs for the various
dynamic registration methods.

I'm curious to see what the devs lurking here think.  What should the
behavior be?  It seems like the spec could use some tightening here either
way.

Thanks for your time.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat Native 2.0.8 released

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 2.0.8 stable.

The key features of this release are:

- Fix a crash on Windows when SSLContext.setCACertificate() is invoked
  with a null value for caCertificateFile and a non-null value for
  caCertificatePath
- The windows binaries in this release have been built with OpenSSL
  3.0.14

The 2.0.x branch is primarily intended for use with Tomcat 10.1.x or 
later but can be used with earlier versions as long as the APR/native 
connector is not used.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi

The Apache Tomcat Native Library 2.0.x provides an API for using OpenSSL 
for SSL networking with Apache Tomcat.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

AW: Problems with the most problematic of our Tomcat installations on IBM Midrange (cross-posted to Midrange and Tomcat Lists)

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello James,

> -Ursprüngliche Nachricht-
> Von: James H. H. Lampert 
> Gesendet: Dienstag, 23. Juli 2024 19:44
> An: Midrange Systems Technical Discussion  l...@lists.midrange.com>; Tomcat Users List 
> Betreff: Problems with the most problematic of our Tomcat installations on
> IBM Midrange (cross-posted to Midrange and Tomcat Lists)
> 
> Ladies and Gentlemen:
> 
> We still have a chronic Tomcat crashing problem at one of our installations.
> 
> The weirdest thing about this is that while this is certainly *one* of our
> heaviest-usage installations, it's not *the* heaviest.
> 
> We already have Tomcat shutting down and restarting itself every night.
> And we have the Catalina job and its associated JVM job running in a private
> subsystem, with a 7G private memory pool before it starts to dip into the base
> memory pool. And we're launching with (according to
> catalina.out) -Xms4096m Xmx5120m.
> 
> Our webapp has integration with M$ Office 365, which this installation uses.
> 
> The usual pattern when it starts to get into trouble may be connected with
> that integration. Looking at a typical crash in catalina.out, I see several 
> OAuth2
> errors that appear to involve an expired token, producing lengthy (over 50
> line) Java stacktraces.
> 
> Other errors seem to involve messages from graph.microsoft.com involving
> "item not found," that seem to be connected with email attachment
> downloads from Office365.
> 
> Then a NullPointerException is thrown, producing a stacktrace of over 60 
> lines.
> 
> Then another Microsoft "item not found," like the previous one.
> 
> Then a handshaking error. Not sure what the handshaking error is *with.*
> 
> Then Tomcat runs out of memory in the Java heap space, does a dump, and


If you have a dump on disk, this would be a good start for further 
investigation.
I usually use MAT https://eclipse.dev/mat/ to analyze the dump and figure out 
what is occupying the memory.
After an OOM, the application is usually not stable anymore because you don’t 
know beforehand which threads exited.
Therefore, I would focus on the memory issue.


> everything hits the proverbial fan. 4775 lines of catalina.out entries before 
> we
> manually shut it down with extreme prejudice and restart it,
> 508 of them before the first out-of-memory error, the rest after.
> 
> And yes, I've packaged up an excerpt to send to our webapp developers, to
> see if they can make head or tail of what went wrong.
> 
> Anybody have any suggestions of what to look for?
> 
> --
> JHHL
> 
> -
> 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: Reg: tomcat CPU spikes

[Mark Thomas]

On 22/07/2024 17:35, Christopher Schultz wrote:

Jalaj,

On 7/19/24 14:28, Jalaj Asher wrote:
This is the warning message we get when cachingAllowed is not set to 
false


org.apache.catalina.webresources.Cache.getResource Unable to add the 
resource at [/WEB-INF/classes/] to the cache for web application 
[/x] because there was insufficient free space available after 
evicting expired cache entries - consider increasing the maximum size 
of the cache.


Okay, I see it. Specifically, it is a WARN message which is usually not 
suppressed in a production configuration.


@markt @remm what do you think about making this another of those "WARN 
the first time, DEBUG thereafter" kinds of messages?


It seems like if a cache is full, the operator SHOULD get a 
notification, but if the cache is thrashing, printing an error a huge 
number of times doesn't seem like it's terribly helpful. It just fills 
the disk.


I'm not sure. If this happens occasionally, then an occasional message 
seems reasonable. If the cache is thrashing then that is bad and a slew 
of log messages highlighting that doesn't seem unreasonable.


Is there a valid case where you would want the cache to thrash?

Mark




-chris


-Original Message-
From: Jalaj Asher
Sent: Tuesday, July 16, 2024 1:30 PM
To: Tomcat Users List 
Subject: RE: Reg: tomcat CPU spikes


space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
1. Also interesting. Can you post one of those messages here? Was 
there a stack trace shown or just the warning?


 It is just the warning. No stack trace. I will work on recreating 
this since all our environments has this disabled.


2. Interesting. How much static content do you have? This seems like a 
good use-case for a reverse-proxy to handle your static    content for 
you.
We have not collated the complete size of it. But are reasons we 
cannot do that.


Also I was reviewing some older heap dumps and I could see that the 
jars are getting cached in tomcat even with cachingAllowed=false.


Also this is not a consistent issue once it happens it takes sometime 
for the stack to go away as well as post tomcat reboots the problem 
goes away with the same settings and we do see that the wars are 
getting deployed during tomcat startup as well.


Regards

Jalaj P Asher


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 16, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside 
of eClinicalWorks. Always use caution when opening attachments, 
clicking links, or when responding to this email. If you feel this is 
a phishing scam, please use the Phish Alert Report button in Outlook.



Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.
Interesting. How much static content do you have? This seems like a 
good use-case for a reverse-proxy to handle your static content for you.



2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
Also interesting. Can you post one of those messages here? Was there a 
stack trace shown or just the warning?


-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source 
outside of eClinicalWorks. Always use caution when opening 
attachments, clicking links, or when responding to this email. If you 
feel this is a phishing scam, please use the Phish Alert Report 
button in Outlook.



Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleast 4 years since cachingAllowed had some changes in
tomcat 8 which was resulting in it caching all static content as well
as jsps and jars and our though process was if we have static content
being cached on the client end and jsps in the work folder each time
on access we don’t need the cache.

Does the cache actively hurt you?

Is there a way to cache just the jars and not every thing else in 
memory ?


I think the short answer is "no there is not a way to do this" but I 
may be wrong.


The long answer might be "maybe, but you will have to play games with 
 and  and maybe some other things to get 
it working.


I would save yourself some complexity and simply enable caching.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 12, 2024 4:02 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an Externa

Re: NoClassDef error

[Mark Thomas]

On 22/07/2024 15:31, Mcalexander, Jon J. wrote:

Hello,
I have an application team that is receiving the following exception after 
upgrading to Tomcat 9.0.90.

Exception java.lang.NoClassDefFoundError: 
org/apache/tomcat/dbcp/pool2/BasePooledObjectFactory

If they revert back to 9.0.89 it once again works. Was there a change to this 
component between 89 and 90?


Unused code was removed. That was one of the classes that was removed.

Applications should not be using Tomcat's internal fork of Commons Pool. 
They should add the Commons Pool JAR to WEB-INF/lib and use it directly.


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.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat http header size too large!

[Mark Thomas]

On 14/07/2024 00:28, Pradeep wrote:

Hi,

I need some tips to solve below issue.
I am getting 431 http error in API (code running in tomcat) when header
size crosses 8KB. Tomcat server doesn't process request if header size is
more than 8KB.
I tried adding below properties to increase the header size in Springboot
application.yaml:

server:
   tomcat:
   max-http-header-size: 16KB

Above solution didn't work, please advice if any other way can achieve
increasing header size.


You might be better off seeking help from the Spring community. That 
looks like the right property to set to me but there may well be some 
detail I am missing.


Another thing to check is how big your headers are. Are you sure 16KB is 
enough?


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Inquiry about CVE-2024-5535 Vulnerability in Tomcat 10.1.20 Version

[Mark Thomas]

On 06/07/2024 05:08, Zhong, Peyton wrote:

Dear Tomcat Community,

I am writing to inquire about the potential impact of the recently detected critical 
vulnerability: CVE-2024-5535 
(9.1 CRITICAL / CVSS v3), in OpenSSL 3.0.13 on the Tomcat 10.1.20 version. According 
to Black Duck Binary Analysis (BDBA) scans, this vulnerability has been identified 
within the Tomcat 10.1.20 version. There are other detected vulnerabilities inside 
OpenSSL on Tomcat, such as CVE-2024-4603
The detected file is: apache-tomcat-10.1.20/bin/tcnative-2.dll

Given this disconcerting discovery, we are seeking clarification on how 
CVE-2024-5535 may affect the Tomcat 10.1.20 version. It is of utmost importance 
for us to understand the implications of this vulnerability and to identify any 
available mitigations or patches to address this issue.

Your prompt attention to this matter is highly valued, and we would be grateful 
for any assistance or guidance you can provide to help us navigate this 
potential security concern.

Thank you for your time and consideration.


Another illustration of why CVSS scores are a bad idea.

Did you read the description from the OpenSSL project for CVE-2024-5535? 
Its severity is low, not critical. If you did read the descrition, did 
you check the Tomcat Native source code to see if Tomcat uses the method 
in question?


Same questions for CVE-2024-4603.

For CVE-2024-4603 did you read the description from the OpenSSL project? 
Are you using an affected configuration? If yes, can you switch to one 
that isn't affected?


You have access to all the information you need to be able to answer 
your questions yourself. If it is important to you as you say it is then 
why are you asking us to do the work for you rather than doing it yourself?


There are no plans at present for a new Tomcat Native release to pick up 
an updated OpenSSL version for the Windows binaries. However, given that 
some valid/likely configurations are affected, it is probable that there 
will be a Tomcat Native release some time this month so it can be picked 
up for the August Tomcat releases.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] New committer: Dimitris Soumis

[Mark Thomas]

On behalf of the Tomcat committers I am delighted to announce that
Dimitris Soumis (dsoumis) has been voted in as a new Tomcat committer.

Please join me in congratulating Dimitris.

Kind regards,

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] Apache Tomcat 11.0.0-M22 (beta) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M22 (beta).

Apache Tomcat 11 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 available to aid this process.

Apache Tomcat 11.0.0-M22 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.0-M21 include:

- Move OpenSSL support using FFM to a separate JAR named
  tomcat-coyote-ffm.jar that advertises Java 22 in its manifest.

- When using include directives in a tag file packaged in a JAR file,
  ensure that the include directives are processed correctly.

-  Expand the implementation of the filter value of the Authenticator
   attribute allowCorsPreflight, so that it applies to all requests that
   match the configured URL patterns for the CORS filter, rather than
   only applying if the CORS filter is mapped to /*

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: Tomcat silently shuts down after 10 minutes

[Thomas Meyer]

Hi,


This looks like an orderly shutdown of tomcat, can you attach strace and see if 
tomcat process does receive a signal from somewhere?

Mfg Thomas 

Am 4. Juli 2024 14:46:17 MESZ schrieb Bryan Buchanan 
:
>I'm running Tomcat 9.0.14 on Centos 8 with JDK 15.
>
>Tomcat is loaded in /opt/tomcat, the directory owned by "joe". If I login as 
>"joe" and start Tomcat, everything is fine.
>
>We have people login to the Centos system to run the business application as 
>"mary", "jane", "fred" etc. Sometimes they want to shutdown Tomcat, for 
>example if they wish to load a price update to the DBMS or whatever. To enable 
>them to do this from within the business application, I wrote a setuid() C 
>program which sets the effective user as "joe" and executes 
>/opt/tomcat/bin/shutdown.sh or /opt/tomcat/bin/startup.sh. This does startup 
>Tomcat, but 10 minutes later it dies. Nothing is logged that is unusual. These 
>are the last few lines when it dies:
>
>04-Jul-2024 21:45:01.154 INFO [main] 
>org.apache.catalina.startup.Catalina.start Server startup in [54,789] 
>milliseconds
>04-Jul-2024 21:54:10.149 INFO [Thread-3] 
>org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler 
>["http-nio-8080"]
>04-Jul-2024 21:54:10.157 INFO [Thread-3] 
>org.apache.catalina.core.StandardService.stopInternal Stopping service 
>[Catalina]
>04-Jul-2024 21:54:10.194 WARNING [Thread-3] 
>org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web 
>application [TPDRESTServer] registered the JDBC driver [org.postgresql.Driver] 
>but failed to unregister it when the web application was stopped. To prevent a 
>memory leak, the JDBC Driver has been forcibly unregistered.
>04-Jul-2024 21:54:10.196 WARNING [Thread-3] 
>org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The 
>web application [TPDRESTServer] appears to have started a thread named [Tomcat 
>JDBC Pool Cleaner[862048902:1720093501299]] but has failed to stop it. This is 
>very likely to create a memory leak. Stack trace of thread:
>java.base@15/java.lang.Object.wait(Native Method)
>java.base@15/java.util.TimerThread.mainLoop(Timer.java:553)
>java.base@15/java.util.TimerThread.run(Timer.java:506)
>04-Jul-2024 21:54:10.231 INFO [Thread-3] 
>org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler 
>["http-nio-8080"]
>04-Jul-2024 21:54:10.243 INFO [Thread-3] 
>org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler 
>["http-nio-8080"]
>
>My C program is:
>
>int main (int argc, char *argv[]) {
>if (argc != 2) {
>printf("%s", "Syntax: ManageTomcat START|STOP");
>return(0);
>}
>printf("%s\n", argv[0]);
>printf("%s\n", argv[1]);
>
>setuid(1000);
>
>if(strcmp(argv[1], "STOP")) {
>system("/opt/apache-tomcat-9.0.14/bin/startup.sh");
>} else {
>system("/opt/apache-tomcat-9.0.14/bin/shutdown.sh");
>} return(1);
>}
>Any ideas would be appreciated.
>
>Bryan
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[SECURITY] CVE-2024-34750 Apache Tomcat - Denial of Service

[Mark Thomas]

CVE-2024-34750 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M20
Apache Tomcat 10.1.0-M1 to 10.1.24
Apache Tomcat 9.0.0-M1 to 9.0.89

Description:
When processing an HTTP/2 stream, Tomcat did not handle some cases of 
excessive HTTP headers correctly. This led to a miscounting of active 
HTTP/2 streams which in turn led to the use of an incorrect infinite 
timeout which allowed connections to remain open which should have been 
closed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M21 or later
- Upgrade to Apache Tomcat 10.1.25 or later
- Upgrade to Apache Tomcat 9.0.90 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by devme4f from VNPT-VCI.


History:
2024-07-03 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[ANN] New committer: Chuck Caldarale

[Mark Thomas]

On behalf of the Tomcat committers I am delighted to announce that
Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.

Please join me in congratulating Chuck.

Kind regards,

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How to configure Tomcat with a Managed Service Account when using LocalMachine certificates for TLS

[Mark Thomas]

On 25/06/2024 14:27, Gavioto 🕵 wrote:

- how are are starting Tomcat?
  Tomcat is starting as a service with "Domain\account1$" (Managed Service 
Account)

- is Tomcat installed as a Windows service?
  Yes

- which account is Tomcat running under?
  "Domain\account1$" (Managed Service Account)


OK. That clarifies things. Thanks.




My actual configuration

Server version name:   Apache Tomcat/9.0.65
Server version number: 9.0.65.0
Server built:  Jul 14 2022 12:28:53 UTC


Getting on for two years old. There are known security vulnerabilities 
in that version. You definitely want to make sure they don't impact your 
environment and you may want to think about upgrading.






Attribute names are case-sensitive. You have serveral starting with an 
upper case 'K' when they should all be lower case.


I'd expect you to see some warnings in the logs on startup about 
unrecognised attributes.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How to configure Tomcat with a Managed Service Account when using LocalMachine certificates for TLS

[Mark Thomas]

A few questions:

- how are are starting Tomcat?

- is Tomcat installed as a Windows service?

- which account is Tomcat running under?

There are a few references to "user" in your question. It is not clear 
if this is:

- the user administering a Tomcat service
- a user that is starting Tomcat from the command line
- the user that the Tomcat service is running as
- something else

Mark


On 25/06/2024 11:30, Alberto Corral wrote:

Hello!

After some research, docs, and test, I didn't found an answer to my issue.

I'm writing to the list  because I have to configure a probably not very common 
Tomcat configuration and didn't found correct configuration of if it is posible 
to do it.
Also I didn't find previous information or examples on internet and the wiki.

There is a similar question in Server Fault 
https://serverfault.com/questions/1161457/can-i-use-certificates-in-the-local-machine-from-a-managed-service-account,
 but not solved yet.

The configuration has been also involved with a JDK recent bug-fix (but 10 
years old), but this part is fixed using latest available JDK versions.
So I think it would be valuable to document an Use Case based on real 
experience that can be both, tested in future versions, and also useful for 
future users, available in the wiki or official docs :-)

May be what's I'm trying to do is not really possible, but need to know if this 
is a Tomcat limitation or a Windows one.

My actual configuration

Server version name:   Apache Tomcat/9.0.65
Server version number: 9.0.65.0
Server built:  Jul 14 2022 12:28:53 UTC
Architecture:  amd64
OS Version:10.0
OS Name:   Windows Server 2019
JVM Vendor:Eclipse Adoptium
JVM Version:   11.0.23+9
Java Home: 
C:\OpenJDK11U-jdk_x64_windows_hotspot_11.0.23_9\jdk-11.0.23+9

Actual secure configuration used:




Configuration:
- The certificate is in the LOCALMACHINE Windows Storage and allows read access to the 
user "account1$" which is an AD Managed Service Account.
-

Facts:
- If the user have read access but not local admin, then the previous stack 
trace is generated.
- If I give local Admin rights to the service account, it seems can access to 
the Certificate Storage, in other case, the previous Stack Trace is generated.
- Unless I gave local Admin rights, apache opens port 8443, but doesn't respond 
to requests on 8443 when testing and no error in logs appears.

What is the question is "How to configure Tomcat with a Managed Service Account when 
using LocalMachine certificates for TLS"

Notes:
- JDK 11.0.20+ is required due a well known bug that has been backported from JDK 21  
[JDK-6782021] It is not possible to read local computer certificates with the SunMSCAPI 
provider - Java Bug System (openjdk.org) 
(https://bugs.openjdk.org/browse/JDK-6782021) and [JDK-8303520] It is not possible to read 
local computer certificates with the SunMSCAPI provider - Java Bug System 
(openjdk.org) (https://bugs.openjdk.org/browse/JDK-8303520)

Next program can help to check different configurations, and it works when the 
certificate has read permission for the user who is running it.

// JDK8313367test.java - Simple test case to demonstrate OpenJDK defect 
JDK-8313367
// References:
// * https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8313367
// * 
https://stackoverflow.com/questions/75255985/java-keystore-type-windows-my-root-localmachine-requires-administrator-permissio

/*
Here is the command line to run the test using JDK 11.0.20+,  17.0.20+ or 
20.0.2+
java --add-modules=jdk.crypto.mscapi 
--add-exports=jdk.crypto.mscapi/sun.security.mscapi=ALL-UNNAMED 
JDK8313367test.java
*/

import java.io.*;
import java.security.KeyStore;
import java.security.Security;
import java.util.Enumeration;
import sun.security.mscapi.SunMSCAPI;

public class JDK8313367test {
 public static void main(String[] args) {
 try {
 Security.addProvider(new SunMSCAPI());
 KeyStore keyStore = 
KeyStore.getInstance("Windows-My-LOCALMACHINE");
 // When running as non-elevated, the SunMSCAPI provider, enhanced 
with JDK-6782021, incorrectly
   // triggers system error 5 "Access is denied" when 
attempting to load the keystore when invoking the following method:
   keyStore.load(null, null);
 Enumeration aliases = keyStore.aliases();
   // Print Friendly Names, a.k.a. aliases, of each certificate 
in the keystore
 for (int i = 0 ; aliases.hasMoreElements() ; i++) {
 System.out.println( aliases.nextElement() );
 }
 } catch (Exception e) {
 throw new RuntimeException(e);
 }
 }
}

Pending tests:
- What I haven't tested, but it is an idea to test, is to launch this code from 
Tomcat and validate if it works (It isn't possible to run a CLI program using a 
Managed Service Acc

RE: Isolating the Root Cause of "Connection Refused"

[Thomas Meyer]

Hi,

No I don't think so. Best is to check ulimit for your tomcat processes.
Also fd count is available as jmx property I think, but not sure if it does 
contain all kinds of FDs.
You may want to monitor FD count Vs max FD.

Mfg
Thomas 

Am 24. Juni 2024 22:47:52 MESZ schrieb Eric Robinson :
>> -Original Message-
>> From: Chuck Caldarale 
>> Sent: Monday, June 24, 2024 1:40 PM
>> To: Tomcat Users List 
>> Subject: Re: Isolating the Root Cause of "Connection Refused"
>>
>>
>> > On Jun 24, 2024, at 15:36, Eric Robinson  wrote:
>> >
>> >> -Original Message-
>> >> From: Chuck Caldarale 
>> >> Sent: Monday, June 24, 2024 1:29 PM
>> >> To: Tomcat Users List 
>> >> Subject: Re: Isolating the Root Cause of "Connection Refused"
>> >>
>> >>
>> >>> On Jun 24, 2024, at 15:19, Eric Robinson 
>> wrote:
>> >>>
>> >>> We have a tomcat server that is not that busy. It has 100 tomcat
>> >>> instances
>> >> running, but it handles a few hundred connections per second total,
>> >> across all of them. It intermittently rejects connection attempts to
>> >> listening tomcats. The server is running Rocky 8, has 48 cores (about
>> >> 15-40% utilized), 1T RAM (400G free), with NVME storage. 'sar' shows
>> almost 0% iowait.
>> >>>
>> >>> During production:
>> >>>
>> >>> *   /proc/sys/net/netfilter/nf_conntrack_count shows anywhere from 100K
>> to
>> >> 250K connections
>> >>> *   /proc/sys/net/netfilter/nf_conntrack_max is set to 2M.
>> >>> *   netstat -an|wc -l usually shows 90-150K connections
>> >>>
>> >>> Obviously, the TCP stack must be running into some resource
>> >>> limitation, or
>> >> some kind of race condition. I've been working the issue for hours
>> >> and days, without success. How can I determine exactly why the
>> >> tomcats intermittently reject connections?
>> >>
>> >>
>> >> Perhaps some of the Tomcat processes are occasionally running out of
>> >> file descriptors?
>> >>
>> >
>> > Great thought. Wouldn't tomcat log a message somewhere if that were the
>> case?
>>
>>
>> No - Tomcat would never see the request and would have no knowledge that the
>> OS blocked the connection attempt.
>>
>
>But the OS should log something, I assume? I don't see anything in dmesg or 
>messages.
>
>>   - Chuck
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>Disclaimer : This email and any files transmitted with it are confidential and 
>intended solely for intended recipients. If you are not the named addressee 
>you should not disseminate, distribute, copy or alter this email. Any views or 
>opinions presented in this email are solely those of the author and might not 
>represent those of Physician Select Management. Warning: Although Physician 
>Select Management has taken reasonable precautions to ensure no viruses are 
>present in this email, the company cannot accept responsibility for any loss 
>or damage arising from the use of this email or attachments.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.