from:"Christopher Schultz"


Ammu,

On 4/19/24 08:32, lavanya tech wrote:

Thank you very much. I removed  for example.com as well as adding an
 in server.xml
I copied context.xml file
/git/app/apache-tomcat-10.1.11/webapps/towl/META-INF/context.xml
Removed < in rewrite.config files.

But still I dont redirect the URL.


If you have  in server.xml and also your application in the 
webapps/ directory, then you will be double-deploying your application.


Re-name /git/app/apache-tomcat-10.1.11/webapps/towl/ to be 
/git/app/apache-tomcat-10.1.11/webapps/ROOT (the capitals are important) 
and remove the  element from your server.xml.


Then start your server and read the logs.


*nslookup alias.example.com <http://alias.example.com>
gives-->Non-authoritative answer:Name: www.example.com
<http://www.example.com>Address:  192.168.200.10Aliases:  alias.example.com
<http://alias.example.com>*


Just to give some information here, *www.example.com
<http://www.example.com>* has alias* "alias.example.com
<http://alias.example.com>"*
But https://www.example.com:/example --> works fine with out issues but
the alias doesnot works (https://alias.example.com)
So i am not sure if the redirect url helps or if its correct


Your rewrite configuration says that you have to be using host 
"example.com" but your request goes to www.example.com. Your 
configuration should only redirect a request such as:


$ curl -v http://example.com:/something

HTTP/1.1 301 Moved Permanently
...
Location: https://www.example.com:/example

If you make a request like:

$ curl -v http://www.example.com:/something

I wouldn't expect a redirect because of your "host" condition. The 
"%{HTTP_HOST} example.com" looks at the entire Host header and not just 
anything that ends in "example.com". You'd have to use a glob/regex if 
you wanted to check for [anything and maybe nothing.]example.com.


You'd also have to make sure that your application is serving responses 
to requests to / which is why I'm recommending you use the ROOT web 
application name instead of "towl".


-chris


On Fri, Apr 19, 2024 at 1:21 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Ammu,

On 4/18/24 09:34, lavanya tech wrote:

I am attaching server.xml and context.xml and rewrite.config files.
The paths are

/git/app/apache-tomcat-10.1.11/webapps/towl/context.xml

  
/>

  



This file ^^^ is in the wrong place. It should be in
/git/app/apache-tomcat-10.1.11/webapps/towl/META-INF/context.xml


/git/app/apache-tomcat-10.1.11/webapps/towl/WEB-INF/rewrite.config

https://www.example.com:/example [R=301,L]


Why do you have < symbols at the beginning of these lines?


server.xml


  > [...]






It's best not to define any  in server.xml. I would remove this
 entirely and allow Tomcat to auto-reploy from your
webapps/towl directory. If you need this application to be deployed as
the ROOT context (on / and not /towl) then you should re-name
/git/app/apache-tomcat-10.1.11/webapps/towl to
/git/app/apache-tomcat-10.1.11/webapps/ROOT

You also don't need a  for example.com as well as adding an
 for the same domain (though this is probably to anonymize the
configuration). You can feel free to simply use the "localhost" 
as the default  and deploy everything into it. This makes your
configuration changes relative to a stock Tomcat less significant and
easier to apply to new versions if/when necessary.

-chris


On Thu, Apr 18, 2024 at 2:17 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Ammu,

On 4/18/24 07:45, lavanya tech wrote:

I added classname rewrite valeus in contex.xml file .

   
   
className="org.apache.catalina.valves.rewrite.RewriteValve"

/>

   

created rewrite.config so both of them is located under  conf under
apache-tomcat.


   https://www.example.com:/example [R=301,L]

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder

of

apache-tomcat . I placed and restarted tomcat webserver but still it
doesnot redirect.


Can you give full paths to both server.xml and rewrite.config, re-post
your current server.xml  element, and the complete contents of
rewrite.config?

Have you looked at the log files after start?

-chris


On Thu, Apr 18, 2024 at 1:36 PM lavanya tech 


wrote:


Hi Thomas,

Thanks for the fast response.

I added classname rewrite valeus in contex.xml file .

   
   
className="org.apache.catalina.valves.rewrite.RewriteValve"

/>

   

created rewrite.config so both of them is located under  conf under
apache-tomcat.

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder

of

apache-tomcat

Thnks,
Ammu



On Thu, Apr 18, 20

Re: Tomcat closes connections on unexpected status codes


Harri,

On 4/19/24 08:10, Harri Pesonen wrote:

I have developed a restful web service, which uses HTTP response codes 200 OK, 
201 Created, 204 No Content and 404 Not Found.
It does not use 400 Bad Request or 500 Internal Server Error normally.
400 Bad Request is more common than 500 Internal Server Error, which should 
basically never happen.


I disagree. There aren't many good 5xx errors, so sometimes "500 Oops" 
is the best you can do. HTTP 5xx doesn't even really allow you to 
differentiate between "server error" and "application error".



400 Bad Request is the best response in many cases, if client gives some query 
parameter which is not supported by the application logic.


-1

400 means that the HTTP request is bad. In your situation, the HTTP 
request is 100% valid. It's your application that is saying "sorry, 
client, you did something we don't allow". This is an application-level 
error, not a protocol-level error. To me, 400 means "HTTP protocol 
error" and should never be substituted for "application protocol error".



I think that it would be better not to close connection in this case, if the 
error comes from application.
I wonder if there is option for application to define that connection should be 
closed or not after the response has been sent?
Or is the option only from the client.

For me this 404 Not Found is also a small problem, as it is error, but it can 
happen quite often.
HTTP errors are not nice in logs.
Normally if you try to fetch some restful resource, which does not exist, then 
it returns 404 Not Found.
GET /service/resource/id => 404 Not Found
If I now had an option to rewrite the service, I would probably use 204 No 
Content in this case as well, to avoid errors.


404 and 204 are fundamentally different responses. 404 means "this 
resource does not exist" and 204 means "this resource DOES EXIST but it 
doesn't contain anything". Your application may not differentiate 
between those two cases, but as a client I would be confused if "Not 
Found" was replaced by "Found to be empty" in all cases.



204 No Content is normally used with PUT and DELETE requests.


Yes, you can use those. 200 would also make sense and, of course 201 for 
new resources.


-chris


-Original Message-
From: Christopher Schultz 
Sent: perjantai 19. huhtikuuta 2024 14.27
To: users@tomcat.apache.org
Subject: Re: Tomcat closes connections on unexpected status codes

Mark,

On 4/18/24 11:38, Mark Thomas wrote:

On 18/04/2024 15:16, Adwait Kumar Singh wrote:

I think we should *always* close connections in cases where it can
lead to request smuggling vulnerabilities like when there is an error
during header or request line parsing, but allowing the user to
control connection close when the status is being set by the user,
should be safe?


I'm not (yet) convinced distinguishing between those scenarios is
always going to be possible.


It allows users to send back responses like InvalidInputException
with a
400 status without being forced to close the connection.


I appreciate why a 400 is used here but 400 has always struck me as
more for protocol level issues rather than application level issues.


Didn't someone tell me recently that, technically, ANY client-error is allowed 
to trigger a 400 response without being more specific?


That is the fundamental problem here. The status codes are being used
for two completely different purposes.


+1

I've always found it distasteful when REST services do this. To me, 400 means "the request was 
actually malformed". If you need authentication, that's a 401. If you aren't allowed, that's 
403. If you didn't provide a required header, that's a 412, etc. I've usually found the 
"correct"
response code to use for every situation and I've never written an application 
that returns a 400 response directly.

-chris


On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat  wrote:


On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:


On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version

10.1.19)

where we see that HTTP/1.1 connections are closed whenever a
servlet application returns the following status codes: 400, 408,
411, 414,

500,

503, 501. This causes client applications to rapidly reconnect and

induce

high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful

microservices to

communicate errors. Reviewing RFC 9112 I couldn't find any
requirement

for

closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see
the

same

behaviour, we believe that these status codes do not necessitate a
new connection.


The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.


Checking the Tomcat

Re: Tomcat closes connections on unexpected status codes


Pawel,

On 4/18/24 20:21, Pawel Veselov wrote:

On 18/04/2024 15:18, Stefan Ansing wrote:

Hi Rémy, Mark,
I just want to make sure that we’re understanding each other. I can see
that the connection needs to be closed in certain conditions to prevent
request smuggling attacks. I certainly don’t want to change that behaviour.
However, I’m facing a scenario where an application is responding to a
valid request (from HTTP perspective), with a valid response using these
status codes (more specifically status codes 400 and 500).

If the request is a valid HTTP request then a 400 status doesn't seem
appropriate to me.


It's by now, however, a de-facto standard. Every time I try to
determine "which HTTP response should I send back in case of issues
with the data", I find myself scrolling through the list of defined
codes and not finding anything that would otherwise fit. The HTTP
spec states what should the server do in case of HTTP protocol errors
(respond with an appropriate 4xx), but that's all that the spec
covers for the protocol, and it doesn't prohibit use of 400 for
application-level errors. Out of the entire 4xx codes, 400 is (maybe
also 414?) the only one that is used for protocol problems, others
are for application level errors, but they are very specific and
limiting (IMHO).
When you say "protocol problems", what protocol are you referring to? 
Because if the request is readable and syntactically correct, there is 
no protocol problem. Everything else is ... something else. If you are 
establishing a protocol ON TOP OF HTTP then it's a violation of whatever 
protocol THAT is, not HTTP. So it's better to return { "error" : "Foo 
Protocol violation" } with an appropriate HTTP status code, possibly 
even *200*.



Then, how do I return error paths, when implementing things like a web service?
Either returning it with 200 and custom headers that indicate it's an
error response,
or a 400 with the same. In which case, the difference on the client side is -
does it have to logically differentiate valid response from an error based just
on these custom headers/mime type, or differentiate protocol-related 400 from
application-related 400, and can always treat 200 as proper.

Then I look at "what do others do", and I see AWS that uses 400 for all client
errors, and the way a client knows it's an application error is because there is
content that wouldn't be typically returned if there is a protocol problem.
So I follow suit.


If the server is correctly handling that request to generate the
response, a 500 status doesn't seem right either.


Right. 5xx - my fault, 4xx - your fault.


I don’t think that in this scenario a request smuggling attack could be
executed, or am I missing something?

The main issue is if the original request is invalid HTTP there is no
way to determine where the next HTTP request starts.


I'd imagine it reasonable that as long as Tomcat doesn't find any issues
with the HTTP protocol itself - closing connections wouldn't serve any
helpful purpose in that case, except for not having to read the remainder
of the message. I'd like to know how the connection can be mucked up
otherwise, whether a proxy is involved or not.



If there is a proxy in the mix then the risks of something going wrong
tend to go up.


-chris


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

Re: Tomcat closes connections on unexpected status codes


Pawel,

On 4/18/24 20:32, Pawel Veselov wrote:

On Thu, Apr 18, 2024 at 9:40 AM Adwait Kumar Singh  wrote:

  I'm not (yet) convinced distinguishing between those scenarios is always
going to be possible.

I have a Tomcat patch which we use at work to do this, i.e always close the
connection if HTTP parsing fails but not if it's a user set status. I can
create a PR for feedback.


It can't be that straightforward though. The HTTP parsing can very well fail
well past the point the application was invoked, and returned a status, during
chunked request parsing. The server can't respond with another error though,
as the headers are/can be committed, it has no recourse but to try to send them
if possible, and then shutdown the connection.


Assuming that the container is still in charge of the HTTP part of 
things, then the container definitely knows if the request has 
experienced some problem with e.g. chunked content.


Tomcat has private information about requests that it keeps separate 
from what applications can (usually) get access to, and it could simply 
mark a request as "requiring connection termination" and doing that at 
the appropriate time when execution finishes with the application and 
returns to the container.



And handling incomplete body reads from the application is also
going to be a nuisance that has to be dealt with. Tomcat will have to
consume the remainder of the body without application doing so

(Tomcat already does this.)


, which may not be desirable in all cases, and will require either an
API change to be supported as being signalled by the application
(here is my status, but PLEASE don't break the HTTP connection), or
requiring the application to diligently consume the body till the end
before returning service back to Tomcat, or having that as a
configuration parameter.

I'm not sure this is different from today.

A new API isn't strictly necessary, here. The application can 
communicate with the container using request attributes. But I'm not 
sure anything like that is needed.



I actually don't know how Tomcat deals with bodies that aren't fully read by
the app right now. I would very much like to know for sure.


Tomcat does one of two things:

1. Reads the remainder of the request entity and discards it

2. Closes the connection without finishing the read

I believe it tries (1) for a while and, after some configurable number 
of bytes ( maxSwallowSize), it switches to (2) and gives up.


-chris


On Thu, Apr 18, 2024 at 8:42 AM Mark Thomas  wrote:


On 18/04/2024 15:18, Stefan Ansing wrote:

Hi Rémy, Mark,



I just want to make sure that we’re understanding each other. I can see
that the connection needs to be closed in certain conditions to prevent
request smuggling attacks. I certainly don’t want to change that

behaviour.


However, I’m facing a scenario where an application is responding to a
valid request (from HTTP perspective), with a valid response using these
status codes (more specifically status codes 400 and 500).


If the request is a valid HTTP request then a 400 status doesn't seem
appropriate to me.

If the server is correctly handling that request to generate the
response, a 500 status doesn't seem right either.



I don’t think that in this scenario a request smuggling attack could be
executed, or am I missing something?


The main issue is if the original request is invalid HTTP there is no
way to determine where the next HTTP request starts.

If there is a proxy in the mix then the risks of something going wrong
tend to go up.

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: Tomcat closes connections on unexpected status codes

Mark,

On 4/18/24 11:38, Mark Thomas wrote:

On 18/04/2024 15:16, Adwait Kumar Singh wrote:
I think we should *always* close connections in cases where it can
lead to
request smuggling vulnerabilities like when there is an error during
header
or request line parsing, but allowing the user to control connection
close

when the status is being set by the user, should be safe?

I'm not (yet) convinced distinguishing between those scenarios is always
going to be possible.

It allows users to send back responses like InvalidInputException with a
400 status without being forced to close the connection.

I appreciate why a 400 is used here but 400 has always struck me as more
for protocol level issues rather than application level issues.

Didn't someone tell me recently that, technically, ANY client-error is
allowed to trigger a 400 response without being more specific?

That is the fundamental problem here. The status codes are being used
for two completely different purposes.

I've always found it distasteful when REST services do this. To me, 400
means "the request was actually malformed". If you need authentication,
that's a 401. If you aren't allowed, that's 403. If you didn't provide a
required header, that's a 412, etc. I've usually found the "correct"
response code to use for every situation and I've never written an
application that returns a 400 response directly.

-chris

On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat wrote:

On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas wrote:

On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version

10.1.19)

where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414,

500,

503, 501. This causes client applications to rapidly reconnect and

induce

high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful

microservices to

communicate errors. Reviewing RFC 9112 I couldn't find any requirement

for

closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the

same

behaviour, we believe that these status codes do not necessitate a new
connection.

The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.

Checking the Tomcat sources makes me believe that the behaviour is
hard-coded[1]. I'm reaching out here to re-evaluate the list of status
codes and to discuss the possibilities of making the behaviour

configurable.

Making this list of status codes configurable seems reasonable. The
default can stay as current and if users want to change it then they
have to accept the associated security risks.

If it's insecure, then it would still be a valid CVE even if the
configuration is optional. We don't have an "allowSmuggling" attribute
on the connector to relax header or status line parsing, even though
many would have wanted it in the past ...

Rémy

Mark

A colleague of mine reported a bug for this issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901

Kind regards,
Stefan Ansing

[1]:

https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617

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

Re: Tomcat closes connections on unexpected status codes

All,

On 4/18/24 10:16, Adwait Kumar Singh wrote:

I think we should *always* close connections in cases where it can lead to
request smuggling vulnerabilities like when there is an error during header
or request line parsing, but allowing the user to control connection close
when the status is being set by the user, should be safe?

It allows users to send back responses like InvalidInputException with a
400 status without being forced to close the connection.

Maybe the behavior depends upon the source of the response code. If
Tomcat itself determines that the connection should be terminated, it
should. But if the application is the one returning the 4xx error,
Tomcat should not terminate the connection.

Does that sound like a decent compromise and is it even possible to
differentiate?

-chris

On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat wrote:

On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas wrote:

On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version

10.1.19)

where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414,

500,

503, 501. This causes client applications to rapidly reconnect and

induce

high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful

microservices to

communicate errors. Reviewing RFC 9112 I couldn't find any requirement

for

closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the

same

behaviour, we believe that these status codes do not necessitate a new
connection.

The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.

configurable.

Making this list of status codes configurable seems reasonable. The
default can stay as current and if users want to change it then they
have to accept the associated security risks.

Rémy

Mark

A colleague of mine reported a bug for this issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901

Kind regards,
Stefan Ansing

[1]:

https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617

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

Re: Regarding Tomcat url redirection


Ammu,

On 4/18/24 09:34, lavanya tech wrote:

I am attaching server.xml and context.xml and rewrite.config files.
The paths are

/git/app/apache-tomcat-10.1.11/webapps/towl/context.xml

 
 



This file ^^^ is in the wrong place. It should be in 
/git/app/apache-tomcat-10.1.11/webapps/towl/META-INF/context.xml



/git/app/apache-tomcat-10.1.11/webapps/towl/WEB-INF/rewrite.config

https://www.example.com:/example [R=301,L]


Why do you have < symbols at the beginning of these lines?


server.xml


> [...]


   
   


It's best not to define any  in server.xml. I would remove this 
 entirely and allow Tomcat to auto-reploy from your 
webapps/towl directory. If you need this application to be deployed as 
the ROOT context (on / and not /towl) then you should re-name 
/git/app/apache-tomcat-10.1.11/webapps/towl to 
/git/app/apache-tomcat-10.1.11/webapps/ROOT


You also don't need a  for example.com as well as adding an 
 for the same domain (though this is probably to anonymize the 
configuration). You can feel free to simply use the "localhost"  
as the default  and deploy everything into it. This makes your 
configuration changes relative to a stock Tomcat less significant and 
easier to apply to new versions if/when necessary.


-chris


On Thu, Apr 18, 2024 at 2:17 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Ammu,

On 4/18/24 07:45, lavanya tech wrote:

I added classname rewrite valeus in contex.xml file .

  
  
/>

  

created rewrite.config so both of them is located under  conf under
apache-tomcat.


  https://www.example.com:/example [R=301,L]

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat . I placed and restarted tomcat webserver but still it
doesnot redirect.


Can you give full paths to both server.xml and rewrite.config, re-post
your current server.xml  element, and the complete contents of
rewrite.config?

Have you looked at the log files after start?

-chris


On Thu, Apr 18, 2024 at 1:36 PM lavanya tech 
wrote:


Hi Thomas,

Thanks for the fast response.

I added classname rewrite valeus in contex.xml file .

  
  
/>

  

created rewrite.config so both of them is located under  conf under
apache-tomcat.

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat

Thnks,
Ammu



On Thu, Apr 18, 2024 at 1:22 PM Mark Thomas  wrote:


On 18/04/2024 12:05, lavanya tech wrote:

Hi Team,

I am using "Tomcat 10.1" in our environment and I wanted to redirect

url

from https://example.com to https://www.servercom: and for this i
modified the server.xml as below in tomcat config, and the below
configuration doesnot seems to work. Does anyone has ideas. Please

suggest.

The url alone https://www.servercom:/ already works. But just
redirection from the old to one doesnot.


autoDeploy="true">

   
   example.com
   
   
className="org.apache.catalina.valves.rewrite.RewriteValve"/>

   
   
   
   example.com
   
className="org.apache.catalina.valves.rewrite.RewriteValve"/>

   
   
   
   example.com
   
   https://www.servercom:/example/$1 [R=301,L]


1. That isn't valid XML.

2. Where in the Tomcat docs does it say you can nest re-write rules in

a

Host element (or any other element)?


   
   
   
   



You need to configure the RewriteValve.
https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html

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: Regarding Tomcat url redirection

2024-04-18 Thread Christopher Schultz


Ammu,

On 4/18/24 07:45, lavanya tech wrote:

I added classname rewrite valeus in contex.xml file .

 
 
 

created rewrite.config so both of them is located under  conf under
apache-tomcat.


 https://www.example.com:/example [R=301,L]

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat . I placed and restarted tomcat webserver but still it
doesnot redirect.


Can you give full paths to both server.xml and rewrite.config, re-post 
your current server.xml  element, and the complete contents of 
rewrite.config?


Have you looked at the log files after start?

-chris


On Thu, Apr 18, 2024 at 1:36 PM lavanya tech 
wrote:


Hi Thomas,

Thanks for the fast response.

I added classname rewrite valeus in contex.xml file .

 
 
 

created rewrite.config so both of them is located under  conf under
apache-tomcat.

So according to the documentaion they say context.xml should be placed
under webapps and rewrite.config file should be put in WEB-INF folder of
apache-tomcat

Thnks,
Ammu



On Thu, Apr 18, 2024 at 1:22 PM Mark Thomas  wrote:


On 18/04/2024 12:05, lavanya tech wrote:

Hi Team,

I am using "Tomcat 10.1" in our environment and I wanted to redirect url
from https://example.com to https://www.servercom: and for this i
modified the server.xml as below in tomcat config, and the below
configuration doesnot seems to work. Does anyone has ideas. Please

suggest.

The url alone https://www.servercom:/ already works. But just
redirection from the old to one doesnot.


autoDeploy="true">

  
  example.com
  
  
className="org.apache.catalina.valves.rewrite.RewriteValve"/>

  
  
  
  example.com
  
className="org.apache.catalina.valves.rewrite.RewriteValve"/>

  
  
  
  example.com
  
  https://www.servercom:/example/$1 [R=301,L]


1. That isn't valid XML.

2. Where in the Tomcat docs does it say you can nest re-write rules in a
Host element (or any other element)?


  
  
  
  



You need to configure the RewriteValve.
https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html

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: Question on the ErrorReportValve

2024-04-18 Thread Christopher Schultz


Jon,

On 4/17/24 13:26, Mcalexander, Jon J. wrote:

Thank you. The documentation makes it somewhat confusing because it
starts out that a Valve can exist in Engine, Host, and Context
Containers, and then in the subsequent valve list is the
ErrorReportValve, but it doesn’t make it clear as to where it can go.
If we put one in the Engine container, does it then also cover the
Host containers since If you are willing to write-up a documentation patch, we can commit it 
for you.


-chris


From: Konstantin Kolinko 
Sent: Wednesday, April 17, 2024 10:44 AM
To: Tomcat Users List 
Subject: Re: Question on the ErrorReportValve

пн, 15 апр. 2024 г. в 19: 37, Mcalexander, Jon J. : > > Hi all! > Quick question on the ErrorReportValve and location within 
the server. xml file. I know that typically this would be inside


пн, 15 апр. 2024 г. в 19:37, Mcalexander, Jon J.

mailto:jonmcalexan...@wellsfargo.com.invalid>>:






Hi all!



Quick question on the ErrorReportValve and location within the server.xml file. I know that 
typically this would be inside the  element, but if you have Multiple 
 elements, do you add the valve to each Host section, or can it be placed at the 
Engine or even Server level?




Unlikely.



A Valve is expected to be in a certain place on the request processing pipeline.



Note that a Host has an attribute named errorReportValveClass. If you

do not specify a Valve explicitly, a default one will be created.



Best regards,

Konstantin Kolinko



-

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: Unexpected behavior of filters

2024-04-16 Thread Christopher Schultz


Konstantin,

On 4/16/24 13:16, Konstantin Kolinko wrote:

вт, 16 апр. 2024 г. в 18:17, Christopher Schultz :


All,

I'm not sure if this is the first time I've tried something like this,
but I was surprised by the behavior I observed today when trying to
configure a new Filter.

I have an existing Filter that looks at Cookies provided in a request.

I wanted to add a new Filter that takes request parameters and returns
them from request.getCookies() but only for a small number of URL
patterns which we handle only internally, both for security (?) and also
for performance, since this isn't a really common thing for us to do.

So I have these two filters:


cookieUserFilter
...



cookieParameterFilter
...



cookieParameterFilter
*.xml.do
/some/specific/pattern



cookieUserFilter
*.do
*.jsp


I have tested that both Filters work as expected when called. However,
when I configure them as above and request /foo.xml.do, only the
cookieUserFilter is being called. The cookieParameterFilter is not being
called.
[...]

What am I missing?

This is Tomcat 9.0.85 and everything is defined in WEB-INF/web.xml.


Hi, Chris!

The Servlet 4.0 specification (the one that applies to Tomcat 9) says:

1) ch. 12.2 Specification of Mappings

"A string beginning with a ‘ *. ’ prefix is used as an extension mapping."

searching for "extension" finds:
2) ch 12.1  Use of URL Paths

"3. If the last segment in the URL path contains an extension (e.g.
.jsp), the servlet
container will try to match a servlet that handles requests for the
extension. An
extension is defined as the part of the last segment after the last ’
. ’ character."

As it says "after the last '.' character" then by this design
*.xml.do cannot match anything.


Aw. I suppose anything else would be terrible for performance.

So the problem is that I was specifying an "extension" mapping that is 
not legal. I don't see anything in the log files, but this seems like a 
good thing to log. I'll check to see if such a thing could be added.


I now have two options:

1. Specify every individual url-pattern that I want to support (which is 
easy: there are a very small number of them)


2. Abort this stupid idea and do something else

I've already opted for #2 anyway because it's less-stupid than trying to 
use request parameters as a proxy for cookies. It also solves like 2 
other problems at the same time, so I like my other solution better.



(You may look at how o.a.catalina.mapper.Mapper actually works.

Look for extensionWrappers and method internalMapExtensionWrapper().)


Thanks for the pointer.

-chris

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

Unexpected behavior of filters

2024-04-16 Thread Christopher Schultz


All,

I'm not sure if this is the first time I've tried something like this, 
but I was surprised by the behavior I observed today when trying to 
configure a new Filter.


I have an existing Filter that looks at Cookies provided in a request.

I wanted to add a new Filter that takes request parameters and returns 
them from request.getCookies() but only for a small number of URL 
patterns which we handle only internally, both for security (?) and also 
for performance, since this isn't a really common thing for us to do.


So I have these two filters:


  cookieUserFilter
  ...



  cookieParameterFilter
  ...



  cookieParameterFilter
  *.xml.do
  /some/specific/pattern



  cookieUserFilter
  *.do
  *.jsp


I have tested that both Filters work as expected when called. However, 
when I configure them as above and request /foo.xml.do, only the 
cookieUserFilter is being called. The cookieParameterFilter is not being 
called. I'm explicitly defining them in that order to ensure that the 
cookieParameterFilter is called /first/ to ensure that the parameters 
are converted into Cookies before the cookieUserFilter is called.


In order to get the cookieParameterFilter to be called, I have to 
configure it like this in my filter-mapping:



  cookieParameterFilter
  *.do
  *.xml.do

  /some/specific/pattern


This means it will apply to all requests, which isn't what I want.

The only thing I can think of is that *.xml.do isn't mapped to any 
specific servlet, while *.do /is/. Will s only apply to URL 
patterns that are explicitly-mapped to a specific servlet?


That doesn't sound right to me. I have other mappings that only map to a 
URL space and not anything that has a specific servlet mapping.


What am I missing?

This is Tomcat 9.0.85 and everything is defined in WEB-INF/web.xml.

-chris

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

Re: Retrieve server.built, server.number





On 4/11/24 10:59, Mark Thomas wrote:



On 11/04/2024 15:49, Bill Stewart wrote:

On Wed, Apr 10, 2024 at 2:14 PM Mark Thomas wrote:


... and it might represent an information leakage vulnerability in your

application. Be Careful.


Shall we start the flame war now on whether exposing the current version
   you are running represents a valid vulnerability or if hiding it is
just security by obscurity? Or do you want to save it for Bratislava?

:)

More seriously, your time is likely to be better spent (in my view)
keeping your Tomcat installations up to date with the latest releases
than it is ensuring that you hide the version number.



The amusing thing (or irritating thing, depending on your point of 
view) is

when a large organization uses a vulnerability scanner and a Tomcat
instance gets flagged as a security risk because it reveals its version
number in the 404 error page. (Yes, this is a real scenario.)


At least it is an easy fix: showServerInfo="false"

assuming that is going to be easier than convincing folks that exposing 
the version number isn't an issue.


+1

Revealing the server version isn't a vulnerability, period. But if your 
operational practices are such that you leave old versions that have 
known published vulnerabilities running in production, then you have 
broken operational practices that need to be fixed.


IMHO, revealing your server version number may be an incentive to keep 
your software up-to-date.


On the flip side, hiding your server's version number is *not a valid 
security control*. If you are advertising your server version number it 
only increases the likelihood of someone identifying your site as 
potentially vulnerable /if you have an old version/.


If a zero-day is published against Tomcat, anyone who wants to attack 
Tomcat-based services will attack anyone they want since the 
vulnerability is likely to affect both old-version and new-version 
deployments.


But well-known vulnerabilities from past versions may make it attractive 
for miscreants to use something like Shodan to search for servers 
running particularly old versions to attack them.


So... if you want to reveal your server version, feel free to do so. But 
make sure you stay up-to-date. You should always stay up-to-date. The 
policy of the Apache Tomcat Security Team is to release security-related 
patches with announcements /coming later/. So any release make be a 
security-related release. You won't know until afterward whether or not 
it's an "important" update.


-chris

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

Re: Question on the ErrorReportValve


Jon,

On 4/15/24 12:36, Mcalexander, Jon J. wrote:

Quick question on the ErrorReportValve and location within the server.xml file. I know that 
typically this would be inside the  element, but if you have Multiple 
 elements, do you add the valve to each Host section, or can it be placed at the 
Engine or even Server level?


The configuration reference doesn't specify, but the Javadoc says it 
"should be" used in  but "should work in ".


I would think you'd want to separately configure them for each , 
anyway.


Is this an academic question? It seems like a very easy think to just 
try out and see what happens. :)


-chris

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

Re: [EXT]Re: .intermittent InvocationTargetException errors

akarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:206)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
 at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:175)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
 at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:653)
 at 
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:419)
 at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:340)
 at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:277)
 at 
com.radiovoodoo.action.ServletDispatcher.service(ServletDispatcher.java:177)
 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:206)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
 at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:175)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:150)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
 at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
 at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
 at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)
 at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
 at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
 at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:391)
 at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
 at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:896)


-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, April 15, 2024 11:09 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: .intermittent InvocationTargetException errors

Rick,

On 4/15/24 10:04, Rick Noel wrote:

Hello,

I am using Tomcat 10 with java 17.

I am getting itermitant jsp compile errors below.

Some times the page compiles correctly but sometimes the page hits result in 
below errors

java.lang.reflect.InvocationTargetException
  at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
  at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:568)
  at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)
  at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)


What is RadioVoodoo?

Is there more of the stack trace?


I found this explanation for possible cause..
Normally "java.lang.reflect.InvocationTargetException" occurs when java 
compiler finds 2 different classes with same name in 2 different packages.
When you are importing both classes at a time and when you are trying to create object of 
that class it throws "java.lang.reflect.InvocationTargetException" exception .
The solution is that when you are creating the object of the class use package 
name also along with class name so that compiler knows what class it has to use.


This is unlikely to be the explanation. I've never seen InvocationTargetException under 
the conditions described. The compiler should never allow you to import two classes with 
the same "simple"
(without package) name, because it's impossible for it to then tell which one 
you mean in a given expression.


I looked at my code in the jsp and the code in question could be mistaking for 
two different classes.
My code is meant to use  java.util.Timezone but my code also has a
com.radiovoodoo.customer.Timezone class


What do your imports look like?


So I thought ah ah will specifical declare the class the I want, so I
changed F

Re: .intermittent InvocationTargetException errors


Rick,

On 4/15/24 10:04, Rick Noel wrote:

Hello,

I am using Tomcat 10 with java 17.

I am getting itermitant jsp compile errors below.

Some times the page compiles correctly but sometimes the page hits result in 
below errors

java.lang.reflect.InvocationTargetException
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.base/java.lang.reflect.Method.invoke(Method.java:568)
 at com.radiovoodoo.display.EvalExpr.evalIdentifier(EvalExpr.java:317)
 at com.radiovoodoo.display.EvalExpr.eval(EvalExpr.java:57)


What is RadioVoodoo?

Is there more of the stack trace?


I found this explanation for possible cause..
Normally "java.lang.reflect.InvocationTargetException" occurs when java 
compiler finds 2 different classes with same name in 2 different packages.
When you are importing both classes at a time and when you are trying to create object of 
that class it throws "java.lang.reflect.InvocationTargetException" exception .
The solution is that when you are creating the object of the class use package 
name also along with class name so that compiler knows what class it has to use.


This is unlikely to be the explanation. I've never seen 
InvocationTargetException under the conditions described. The compiler 
should never allow you to import two classes with the same "simple" 
(without package) name, because it's impossible for it to then tell 
which one you mean in a given expression.



I looked at my code in the jsp and the code in question could be mistaking for 
two different classes.
My code is meant to use  java.util.Timezone but my code also has a  
com.radiovoodoo.customer.Timezone class


What do your imports look like?


So I thought ah ah will specifical declare the class the I want, so I changed
From
private TimeZone customerTimeZone;
to
private java.util.TimeZone customerTimeZone;

so that the compiler will not think to use com.radiovoodoo.customer.Timezone 
but instead always use java.util.TimeZone
But this had no effect.


What do your imports look like?


I still get intermittent java.lang.reflect.InvocationTargetException
Could this be a possible bug in   the class tomcat 10 uses to compile jsp   ->  
org.apache.jasper.servlet.JspServlet


It's possible, but not very likely. We have a pretty good set of unit 
tests, plus we aren't getting any reports from others that the compiler 
is failing in this way.



Is there a different JspServlet class I could use to test that theory out?


I'm curious as to why RadioVoodoo is being invoked during compilation. 
Or is this happening during JSP execution, post-compile? A more complete 
stack trace would reveal that.


-chris

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

Re: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails


Rick,

On 4/15/24 08:12, Rick Noel wrote:

Hi Chuck,
Your suggestion did not work.

I defined Membership as suggested...


and still getting this in the logs

org.apache.catalina.ha.session.DeltaManager.startInternal Starting clustering 
manager at [##0001]
15-Apr-2024 07:55:36.744 INFO [main] 
org.apache.catalina.ha.session.DeltaManager.getAllClusterSessions Manager 
[##0001]: skipping state transfer. No members active in cluster group

Do you think the transfer is not happening because the application is only on 
one machine?
Our Production environment will have  our application on two machines but in our dev environment we 
have only one machine in the "cluster". So we really do not have a "cluster" 
environment.
Again, we would like to know is going on before we introduce clustering in our 
live environment.

We are using Java 17 and Tomcat 10


I've never set up replication in Tomcat, so I may be speaking out of turn.

But is it possible that since you have only a single node (right?), 
Tomcat is really saying "skipping state transfer. No [other] members 
active in cluster group"?


-chris


-Original Message-
From: Chuck Caldarale 
Sent: Saturday, April 13, 2024 4:00 PM
To: Tomcat Users List 
Subject: [EXT]Re: [EXT]Re: Tomcat 10 session replication fails



On Apr 11, 2024, at 09:07, Rick Noel  wrote:

We are getting closer
Changing ports from the 5000 range to the 4000 range stopped two
errors But now I get this..

INFO: Manager [##0001]: skipping state transfer. No members active in
cluster group

How to I make the member machine in the cluster active?



There’s a cluster configuration option that may be coming into play here: 
localLoopbackDisabled. Once upon a time, the JDK method:
 MulticastSocket.setLoopbackMode(boolean disable) did the opposite of 
what one might think from just the method name - passing in true disabled local 
receipt of multicast packets. That method has since been deprecated, and Tomcat 
currently uses this method:
  DatagramSocket.setOption(SocketOption name, T value) which, at 
least in Java 21, operates as you might expect from the name - specifying true enables 
multicast loopback.

However, there’s some interesting logic in Tomcat's handling of 
localLoopbackDisabled that can inverts the config value based on the Java 
level, along with this comment:
 Java < 14, a value of true means loopback is disabled. Java 14+ a 
value of true means loopback is enabled.

Having not dug into the JRE source code for the various Java versions, I’m not yet 
convinced the version checking logic is correct. You might try setting 
localLoopbackDisabled to true in your  config to see if that 
has an effect on your dev system.

Also, let us know what Java version you’re using.

   - Chuck


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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


-
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: [OT] Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while

Marcos,

On 4/11/24 09:52, Marcos Peña wrote:

Thanks for your replies.

My bad assuming the connector configuration applied to all connections but
it makes total sense that applies to incoming connections. That helps a lot.

I have been trying to solve this problem for several days and I was a bit
desperate. I could not find anything in the application code that would
change it at runtime...up to a few minutes ago. I think there is a
SSLSocketFactory that is changing the ciphers at runtime.

That's exactly the kind of thing I would expect to discover given your
description of the symptoms.

-chris

On Thu, Apr 11, 2024 at 2:25 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

Marcos,

Marking as "off topic" because this is not Tomcat-related. Please see
below...

On 4/11/24 08:28, Marcos Peña wrote:

Hi,

I am looking for help with a strange issue we are experiencing when
trying to use Google APIs from a web application that is deployed on
Tomcat 9.0.83.

After a few hours of the server being up and running, all calls to the
Google APIs fail because of SSL handshake errors. Attaching the SSL logs
for your reference.

I see some differences in the ClientHello message. When the handshake
fails, all TLSv1.3 ciphers are ignored, there is no "session id" and
TLSv1.2 is sent as the only supported version.

The Tomcat connector configuration is as follows:

ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256"/>

This configuration is only relevant for INCOMING connections. It has no
bearing on your outgoing HTTP / TLS connections.

I updated Tomcat to use the most recent native library - 2.0.7 - but
that did not help. Below an extract from the server log.

Your use (or not) of tcnative is only relevant for incoming connections.
Without significant work, your outgoing connections will not be using
tcnative for any TLS communications.

2024-04-11 02:12:47,507 INFO
[org.apache.catalina.core.AprLifecycleListener:134] (main) Loaded
Apache Tomcat Native library [2.0.7] using APR version [1.7.4].
2024-04-11 02:12:47,507 INFO
[org.apache.catalina.core.AprLifecycleListener:134] (main) APR
capabilities: IPv6 [true], sendfile [true], accept filters [false],
random [true], UDS [true].
2024-04-11 02:12:47,507 INFO
[org.apache.catalina.core.AprLifecycleListener:134] (main) APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
2024-04-11 02:12:47,514 INFO
[org.apache.catalina.core.AprLifecycleListener:370] (main) OpenSSL
successfully initialized [OpenSSL 3.0.13 30 Jan 2024]

I am not very familiar with the SSL handshake process and do not really
understand what can make it stop working.

My guess is that your /outbound/ HTTP connection manager is having its
configuration changed at runtime. You will have to look at how your
application establishes these outbound connections to determine why the
rules are changing.

-chris

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

Re: [OT] Tomcat 9.0.83 - SSL handshake stops working for Google API calls after a while


Marcos,

Marking as "off topic" because this is not Tomcat-related. Please see 
below...


On 4/11/24 08:28, Marcos Peña wrote:

Hi,

I am looking for help with a strange issue we are experiencing when 
trying to use Google APIs from a web application that is deployed on 
Tomcat 9.0.83.


After a few hours of the server being up and running, all calls to the 
Google APIs fail because of SSL handshake errors. Attaching the SSL logs 
for your reference.


I see some differences in the ClientHello message. When the handshake 
fails, all TLSv1.3 ciphers are ignored, there is no "session id" and 
TLSv1.2 is sent as the only supported version.


The Tomcat connector configuration is as follows:
protocol="com.precisionsoftware.tomcat.Http11Nio2Protocol" 
proxyPort="443" SSLEnabled="true"

         connectionTimeout="6"
         maxThreads="300"
         minSpareThreads="50"
         acceptCount="250"
         maxKeepAliveRequests="1"
maxPostSize="-1"
         relaxedQueryChars='[]|{}^'
         enableLookups="true"
disableUploadTimeout="true"
         URIEncoding="UTF-8"
         compression="force"
scheme="https"
secure="true"
         clientAuth="false"
sslProtocol="TLS"
sslEnabledProtocols="TLSv1.2+TLSv1.3"
         keyAlias="1"
         keystoreFile="../wildcard_odqad.pfx"
         keystorePass="thepassword"
 
ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_CCM_SHA256,TLS_AES_128_CCM_8_SHA256"/>


This configuration is only relevant for INCOMING connections. It has no 
bearing on your outgoing HTTP / TLS connections.


I updated Tomcat to use the most recent native library - 2.0.7 - but 
that did not help. Below an extract from the server log.


Your use (or not) of tcnative is only relevant for incoming connections. 
Without significant work, your outgoing connections will not be using 
tcnative for any TLS communications.


2024-04-11 02:12:47,507 INFO 
  [org.apache.catalina.core.AprLifecycleListener:134] (main) Loaded 
Apache Tomcat Native library [2.0.7] using APR version [1.7.4].
2024-04-11 02:12:47,507 INFO 
  [org.apache.catalina.core.AprLifecycleListener:134] (main) APR 
capabilities: IPv6 [true], sendfile [true], accept filters [false], 
random [true], UDS [true].
2024-04-11 02:12:47,507 INFO 
  [org.apache.catalina.core.AprLifecycleListener:134] (main) APR/OpenSSL 
configuration: useAprConnector [false], useOpenSSL [true]
2024-04-11 02:12:47,514 INFO 
  [org.apache.catalina.core.AprLifecycleListener:370] (main) OpenSSL 
successfully initialized [OpenSSL 3.0.13 30 Jan 2024]


I am not very familiar with the SSL handshake process and do not really 
understand what can make it stop working.


My guess is that your /outbound/ HTTP connection manager is having its 
configuration changed at runtime. You will have to look at how your 
application establishes these outbound connections to determine why the 
rules are changing.


-chris

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

Re: Retrieve server.built, server.number


Mark,

On 4/10/24 16:12, Mark Thomas wrote:



On 10/04/2024 21:15, Christopher Schultz wrote:

All,

On 4/10/24 4:00 AM, Mark Thomas wrote:

On 09/04/2024 17:17, prat 007 wrote:

Hi All,

I would like to know is there a way to find tomcat's server.built and
server.number remotely using tool loke curl or from browser?


In a default installation, no.

You'd have to write a servlet that reported that information and then 
request that page.


... and it might represent an information leakage vulnerability in 
your application. Be Careful.


Shall we start the flame war now on whether exposing the current version 
  you are running represents a valid vulnerability or if hiding it is 
just security by obscurity? Or do you want to save it for Bratislava?


:)


Hey, I've been running Apache-Coyote/1.1 since 1998 and I'm still standing.

More seriously, your time is likely to be better spent (in my view) 
keeping your Tomcat installations up to date with the latest releases 
than it is ensuring that you hide the version number.


+1

Upgrading Tomcat should be something that any application management 
team is comfortable doing. Upgrading with every monthly Tomcat release 
should not be a burden if you choose to do it.


-chris

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

Re: Tomcat log warnings for connection parameter limits?


Baron,

On 4/9/24 16:33, Baron Fujimoto wrote:

I'm investigating occasional 503 errors for our CAS service running in a
Tomcat 10.1.x container. The 503s appear to correlate with some traffic
spikes at the same time.

The connector is configured as follows:

 

Can Tomcat log info such as when the maxThreads or maxConnections limits
are reached? I'm basically trying to see if there is a good way to
more definitively determine what may have caused the 503s and what may be
feasible to mitigate them.


Are you thinking of a debugging feature or something to be left-on for a 
live production system?


Such logging might be considered a DOS vector for a live system: you can 
fill the logs by asking lots of trivial requests.


-chris

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

Re: Retrieve server.built, server.number

2024-04-10 Thread Christopher Schultz


All,

On 4/10/24 4:00 AM, Mark Thomas wrote:

On 09/04/2024 17:17, prat 007 wrote:

Hi All,

I would like to know is there a way to find tomcat's server.built and
server.number remotely using tool loke curl or from browser?


In a default installation, no.

You'd have to write a servlet that reported that information and then 
request that page.


... and it might represent an information leakage vulnerability in your 
application. Be Careful.


-chris

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

Re: Tomcat in a Windows environment : new keystore possibilities

2024-04-08 Thread Christopher Schultz


David,

On 4/8/24 05:35, David Wooffindin wrote:

Referring to the documentation on Apache Tomcat 9 Configuration Reference (9.0.87) - 
The HTTP 
Connector
 keystore types, i wanted to get mentioned that a new set of possibilities is 
available with newer java builds, when using Tomcat in a Windows environment.


As mentioned on the OpenJDK bug tracker: 
https://bugs.openjdk.org/browse/JDK-8286790


The Windows KeyStore support in the SunMSCAPI provider has been expanded to 
include access to the local machine location. The new keystore types are:



Windows-MY-LOCALMACHINE

Windows-ROOT-LOCALMACHINE



The following keystore types were also added, allowing developers to make it 
clear they map to the current user:

  Windows-MY-CURRENTUSER (same as "Windows-MY")

Windows-ROOT-CURRENTUSER (same as "Windows-ROOT")


Alongside other configurations possible on the server side, web certificates 
can be automatically published, renewed and managed with a company's internal 
Active Directory CA. The account running the Tomcat Windows Service needs local 
Administrator rights to be able to refernce these certificate stores.

With this enabled, and setting the server.xml Connector like shown below can 
make certificate management a lot easier.



the use of a predefined Environment Variable for the system name, possible when 
using also this setting  in catalina.properties:
#GPO Managed restricted file: TESTING
#allow_System ENVVar Usage
org.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.Digester$EnvironmentPropertySource

  makes it easier to maintain a common server.xml file through tools like GPO.

Could it be useful to somehow document this, as it does make our WIndows admin 
life easier!!


Hmm.

While this seems really useful, I personally think that encouraging 
Windows admins to run the Tomcat server under a local Administrator 
account would be malfeasance on our part.


Perhaps if there were a native component that could be used as a service 
to request access to the keystore, it would be a more secure setup. In 
the absence of such a component, I think we'll leave the documentation 
along for the time being.


Feel free to publish your findings and setup yourself, but I think we'll 
leave our documentation alone.


-chris

-
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.x to 10.1.x

2024-04-04 Thread Christopher Schultz


Amit,

On 4/4/24 22:21, Amit Pande wrote:

I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1 
(10.1.20).

https://tomcat.apache.org/migration-10.1.html Using the migration tool, I have 
migrated the applications (which use Spring libraries 5.x).

While testing the migrated apps( which use web socket), ran into:


org.springframework.web.util.NestedServletException: Handler dispatch failed; 
nested exception is java.lang.NoSuchMethodError: 'void 
org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta.servlet.http.HttpServletRequest,
 jakarta.servlet.http.HttpServletResponse, 
jakarta.websocket.server.ServerEndpointConfig, java.util.Map)


https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/tomcat/websocket/server/WsServerContainer.java

* @deprecated This method will be removed in Apache Tomcat 10.1 onwards. It 
has been replaced by
  * {@link #upgradeHttpToWebSocket(Object, Object, 
ServerEndpointConfig, Map)}
  */
 @Deprecated
 public void doUpgrade(HttpServletRequest request, HttpServletResponse 
response, ServerEndpointConfig sec,
 Map pathParams) throws ServletException, 
IOException {
 UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
 }

Is this an issue with the migration tool to appropriately replace the removed 
methods?

Or the applications using web sockets with Tomcat 9.x are required to be 
updated before moving to Tomcat 10.1, instead of using the migration tool as an 
intermediate step to upgrade to Tomcat 10.1 without having to update the 
applications at the same time?
FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.


The Migration Tool doesn't rewrite your code, it only rewrites the class 
names referenced by your class files. (Okay, it also re-writes strings 
in your files which match those class names as well.) But it will not 
change method calls. It is not a Deprecation Cleanup Tool.


You should change your Java EE-compatible application to use 
upgradeHttpToWebSocket(Object, Object, ServerEndpointConfig, Map) first, 
then run the Migration Tool on your application.


-chris

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

Re: org.apache.catalina.valves.RemoteAddrValve

2024-04-04 Thread Christopher Schultz


Eric,

On 4/4/24 13:43, Eric Fetzer wrote:

Hi All,

When I originally set up my tomcat instance, I added the following to allow
manager access under /opt/tomcat/webapps/manager/META-INF/context.xml:



That worked wonderfully.  Now I'm trying to add another IP range by
changing it to:



This is not working.  I tried to use 2\.4\.6\.\d+ as well but that didn't
work either.  I've verified I can get to port 8080 from the IP locations.
Any idea what I'm doing wrong or do you have a means to troubleshoot this?


I'm glad you are reporting that the issue is elsewhere and not a problem 
with your use of RemoteAddrValve.


But I'd like to point out that since these are regular expressions, your 
specific use of them can lead to unintended consequences. For example:


1.3.5.*

This will allow anyone from 1.3.5.1 or 1.3.5.99 or 1.3.5.254. That's 
probably fine. But it will also allow anybody from 103.50.99.24 as well. 
That probably wasn't intended.


Changing it to the properly-escaped 1\.3\.5 but also trailing \..* (note 
there are two periods there) really means 1.3.5.whatever.


Using \d isn't strictly necessary but it does make it clear that you 
aren't expecting non-digits e.g. hostnames.


As you mentioned elsewhere in this thread, you thought it was "tomcat 
language". When it comes to security controls, /please read the 
documentation/ because knowing that it is a regular expression and not a 
"tomcat language" can mean the difference between configuring a security 
control properly or improperly.


-chris

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

Re: [EXT]Re: how to define database resource in just context.xml or server.xml


Rick,

On 3/29/24 14:33, Rick Noel wrote:

Our application is really a suite of 5applications.  And the
server.xml  I am talking about is on our dev machine, where we want
to run all 5 apps on the one web server.

The context.xml has global enviroiment variables (like mail server
related vars) that all the dev applications use. All the different
dev applications also use the same database.

So that is why we define resources in the context.xml  file
It sounds like you really *do* want to define the JDBC/JNDI resource in 
server.xml and the link it to your applications.


I think the correct way to do that is by defining it in server.xml and 
then linking it through your applications' WEB-INF/web.xml files.


You should not have to touch CATALINA_BASE/conf/context.xml.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, March 29, 2024 2:21 PM
To: Tomcat Users List ; Rick Noel 

Subject: Re: [EXT]Re: how to define database resource in just context.xml or 
server.xml

Rick,

On 3/29/24 11:56, Rick Noel wrote:

If have the resource defined in
CATALINA_BASE/conf/context.xml
And
CATALINA_BASE/conf/server.xml


You really shouldn't have anything custom in CATALINA_BASE/conf/context.xml. 
That will affect every application deployed on the server. Perhaps you only 
have a single application deployed, but things can get really confusing when 
you edit that file.
It also makes upgrades more difficult.

I would recommend taking your  from CATALINA_BASE/conf/context.xml 
and putting it into the proper place:
your application's META-INF/context.xml file. You will need to surround it with 
 ...  since that file defines the context.

If you have  in your CATALINA_BASE/conf/server.xml file, you should 
remove it. If you want to disable auto-deploy, then you can always copy your 
application's META-INF/context.xml file into 
CATALINA_BASE/conf/[engine]/[host]/[contextpath].xml.

Finally, you should be able to delete your  from your 
CATALINA_BASE/conf/server.xml file entirely.

Do you have anything in your web.xml that is related? For example:


  jdbc/foo
  javax.sql.DataSource
  Container


I have one of those in my web.xml, but it's not clear to be whether or not I 
actually need it. I have *one* of them but my application uses two different 
JDBC resources. Both are declared in META-INF/context.xml and both are 
available to the application.

I think you need to use  in web.xml when you define "global naming 
resources" in server.xml. But if you put them into META-INF/context.xml it's obvious that 
(a) they aren't global and (b) the application expects them.

So I would remove any global naming resources you may have in server.xml and 
also remove anything you don't need in web.xml.

Doing all this will make upgrading Tomcat much easier.

-chris


-Original Message-----
From: Christopher Schultz 
Sent: Friday, March 29, 2024 11:47 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: how to define database resource in just context.xml
or server.xml

Rick,

On 3/29/24 09:48, Rick Noel wrote:

Can someone tell me why I need to have my database source defined in
both my context.xml and server.xml? I thought we are suppose to
define it in only one location?

It's definitely not a requirement to specify it in both places.


I can only log into my app if I have it defined in both my
context.xml and server.xml

Below  is my database resource   as defined in server.xml..

I have xxx out postgres URL for security reasons








 



Below is my database resource   as defined in context.xml




   



  


Which context.xml are you talking about? The one in CATALINA_BASE/context.xml 
or the one in your application's META-INF/context.xml?

Have you defined your  in CATALINA_BASE/conf/server.xml, or are you 
using only META-INF/context.xml?

-chris

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


-
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.

Re: FW: [EXT]Re: how to define database resource in just context.xml or server.xml


Rick,

On 3/29/24 14:05, Rick Noel wrote:

Chris,

I found I could use a ResourceLink element and put it in my context.xml file.
The name in that ResourceLink is the name of resource that I have fully defined 
in my server.xml.
Sot the context.xml points to the fully define resource which is in my 
server.xml


That's definitely a possibility as well.

I work on a small team and so separating the JDBC definition from the 
link doesn't make much sense so we don't do it. We also don't like 
polluting our server.xml file so everything goes into META-INF/context.xml.


You really should never change CATALINA_BASE/conf/context.xml, though.

-chris


So snippet from my context.xml file is.



 
 
   


name="jdbc/app-pool"
global="jdbc/app-pool"
   type="javax.sql.DataSource"   />


And snippet from my server.xml is.


   

  
  



Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Rick Noel
Sent: Friday, March 29, 2024 11:57 AM
To: Tomcat Users List 
Subject: RE: [EXT]Re: how to define database resource in just context.xml or 
server.xml

If have the resource defined in
CATALINA_BASE/conf/context.xml
And
CATALINA_BASE/conf/server.xml

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Christopher Schultz 
Sent: Friday, March 29, 2024 11:47 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: how to define database resource in just context.xml or 
server.xml

Rick,

On 3/29/24 09:48, Rick Noel wrote:

Can someone tell me why I need to have my database source defined in
both my context.xml and server.xml? I thought we are suppose to define
it in only one location?

It's definitely not a requirement to specify it in both places.


I can only log into my app if I have it defined in both my context.xml
and server.xml

Below  is my database resource   as defined in server.xml..

I have xxx out postgres URL for security reasons





   






Below is my database resource   as defined in context.xml




  



 


Which context.xml are you talking about? The one in CATALINA_BASE/context.xml 
or the one in your application's META-INF/context.xml?

Have you defined your  in CATALINA_BASE/conf/server.xml, or are you 
using only META-INF/context.xml?

-chris

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


-
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: [EXT]Re: how to define database resource in just context.xml or server.xml


Rick,

On 3/29/24 11:56, Rick Noel wrote:

If have the resource defined in
CATALINA_BASE/conf/context.xml
And
CATALINA_BASE/conf/server.xml


You really shouldn't have anything custom in 
CATALINA_BASE/conf/context.xml. That will affect every application 
deployed on the server. Perhaps you only have a single application 
deployed, but things can get really confusing when you edit that file. 
It also makes upgrades more difficult.


I would recommend taking your  from 
CATALINA_BASE/conf/context.xml and putting it into the proper place: 
your application's META-INF/context.xml file. You will need to surround 
it with  ...  since that file defines the context.


If you have  in your CATALINA_BASE/conf/server.xml file, you 
should remove it. If you want to disable auto-deploy, then you can 
always copy your application's META-INF/context.xml file into 
CATALINA_BASE/conf/[engine]/[host]/[contextpath].xml.


Finally, you should be able to delete your  from your 
CATALINA_BASE/conf/server.xml file entirely.


Do you have anything in your web.xml that is related? For example:

  
jdbc/foo
javax.sql.DataSource
Container
  

I have one of those in my web.xml, but it's not clear to be whether or 
not I actually need it. I have *one* of them but my application uses two 
different JDBC resources. Both are declared in META-INF/context.xml and 
both are available to the application.


I think you need to use  in web.xml when you define 
"global naming resources" in server.xml. But if you put them into 
META-INF/context.xml it's obvious that (a) they aren't global and (b) 
the application expects them.


So I would remove any global naming resources you may have in server.xml 
and also remove anything you don't need in web.xml.


Doing all this will make upgrading Tomcat much easier.

-chris


-Original Message-----
From: Christopher Schultz 
Sent: Friday, March 29, 2024 11:47 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: how to define database resource in just context.xml or 
server.xml

Rick,

On 3/29/24 09:48, Rick Noel wrote:

Can someone tell me why I need to have my database source defined in
both my context.xml and server.xml? I thought we are suppose to define
it in only one location?

It's definitely not a requirement to specify it in both places.


I can only log into my app if I have it defined in both my context.xml
and server.xml

Below  is my database resource   as defined in server.xml..

I have xxx out postgres URL for security reasons





   






Below is my database resource   as defined in context.xml




  



 


Which context.xml are you talking about? The one in CATALINA_BASE/context.xml 
or the one in your application's META-INF/context.xml?

Have you defined your  in CATALINA_BASE/conf/server.xml, or are you 
using only META-INF/context.xml?

-chris

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


-
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: how to define database resource in just context.xml or server.xml


Rick,

On 3/29/24 09:48, Rick Noel wrote:

Can someone tell me why I need to have my database source defined in
both my context.xml and server.xml? I thought we are suppose to
define it in only one location?

It's definitely not a requirement to specify it in both places.

I can only log into my app if I have it defined in both my 
context.xml and server.xml


Below  is my database resource   as defined in server.xml..

I have xxx out postgres URL for security reasons





  


   



Below is my database resource   as defined in context.xml




 






Which context.xml are you talking about? The one in 
CATALINA_BASE/context.xml or the one in your application's 
META-INF/context.xml?


Have you defined your  in CATALINA_BASE/conf/server.xml, or are 
you using only META-INF/context.xml?


-chris

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

Re: [EXT]Re: [EXT]Re: performance tunning of Tomcat 10

2024-03-28 Thread Christopher Schultz


Rick,

On 3/28/24 15:38, Rick Noel wrote:

my bottleneck (app slowness to respond is the at the database
connection max), I am not even going to try and adjust minThreads and
maxThreads. When I tried to increase maxConnection to our database
from and existing connection max of 20, to a new connectionMax of 50,
I got errors, see attached snapshot.

This list strips most attachments including images. Please post text.


I was able to raise the maxConnection to database up to 30 with no
errors, so I am just going to deploy at that level until we upgrade our
Postgess database
We are using a really old Postgres and plan in the near to future to
upgrade that database.


It's not the software version that matters, it's the (possibly virtual) 
hardware.



BTW,
I did find and use the Apache Benchmark tool and was able to see how
our app responses with a test requests of 1 and concurrent
requests of 40 and those results look good to me with worst response
time of only 1000 miliseconds.
That's great for 40 simultaneous requests, but what happens when you 
crank it up to 300? Or 500? Or whatever?


You may want to use JMeter which is a better load-testing tool than 'ab' 
once you get beyond just throwing X requests at a site.


-chris


-Original Message-
From: Christopher Schultz 
Sent: Thursday, March 28, 2024 3:09 PM
To: users@tomcat.apache.org
Subject: [EXT]Re: [EXT]Re: performance tunning of Tomcat 10

Rick,

On 3/27/24 09:22, Rick Noel wrote:

-Original Message-
From: Christopher Schultz 
Sent: Wednesday, March 27, 2024 8:24 AM
To: Tomcat Users List ; Rick Noel

Cc: Voodoo nmulcahy gmail ; David Jung

Subject: [EXT]Re: performance tunning of Tomcat 10

Rick,

On 3/27/24 07:53, Rick Noel wrote:

I was wondering if the apache foundation has any tools we can use to
fine tune Tomcat 10. Tools to deteming how to set the best heap size
for Tomcat startup and the best connection attributes of
minSpareThreads and MaxThreads.

What is your goal?
Our application is a sip phone call handling application.(A voice
response xml application) The goal is to not have  call bottleneck at peak call 
volume.
Sometimes too many folks call at one time hit our app and calls are not handle 
correctly.


I know my application at times will reach 100 concurrent connections

   > and some times goes has high as 500 connections.

Okay.
Well I do not have actual traffic info down to the sec, But from the
application logs I know that that points in the day more than 300
calls can come in


Okay, you need to get better information. Check out this presentation on Tomcat 
monitoring:

https://tomcat.apache.org/presentations.html#latest-monitoring-with-jmx

There is a lot in there, but I do talk about checking on the request processor 
to see how many requests are in-flight at once. You can do the same with your 
database pool.

You'll want to grab samples of those things at regular intervals to see how 
they correlate. I suspect you know when your peak times are, so schedule the 
samples to be taken during that timeframe. You could even sample once per 
second if you wanted to -- the calls are pretty inexpensive.


Should I boost minSpareThreads and maxThread values of what I plan to
use below? > Or why would we not just set very high minSpareThreads
and maxThread values like minSpareThreads =300  and maxThread=1000

This is a snippet of my server.xml



 
  



Also, am I good with setting  
protocol="org.apache.coyote.http11.Http11NioProtocol"
And then setting 

That will tell Tomcat to do HTTP2 Correct?


That's the only way to enable h2. Well... you could use Http11Nio2Protocol, 
too. NIO is the default protocol so you don't even need to add that 
specifically if you don't want to.

Back to threads.

Each thread (unless you go virtual, but that's not really production-ready IMHO at this 
point unless you have very strict circumstances where it will work great for you) takes 
up a bunch of memory, so you can't just set maxThreads=1M. Threads take "time" 
to start, but it's not really that much. If starting and stopping threads is what is 
making your application slow, than you have a very high-performance application and 
environment indeed.

Your question as stated is unanswerable.

You say you are sometimes hitting 500 connections. The default maximum number of 
connections is 1 and you are only using 500. That means you aren't being flooded, 
which is a Good Thing. (BTW: How are you measuring "how many connections" you 
have? Make sure you are measuring the right thing...

I am estimating the actual connections just based on application call logs.

Is your *current* maxThreads set to 500? If so, then your thread pool maximum 
is set to your high-water mark which seems like it should be fine. If you set 
your maxThreads to 1000 you won't get any benefit because only 500 requests are 
ever being sent at once, right?

Re: [EXT]Re: performance tunning of Tomcat 10

2024-03-28 Thread Christopher Schultz

Rick,

On 3/27/24 09:22, Rick Noel wrote:

-Original Message-
From: Christopher Schultz 
Sent: Wednesday, March 27, 2024 8:24 AM
To: Tomcat Users List ; Rick Noel 

Cc: Voodoo nmulcahy gmail ; David Jung 

Subject: [EXT]Re: performance tunning of Tomcat 10

Rick,

On 3/27/24 07:53, Rick Noel wrote:

I was wondering if the apache foundation has any tools we can use to
fine tune Tomcat 10. Tools to deteming how to set the best heap size
for Tomcat startup and the best connection attributes of
minSpareThreads and MaxThreads.

What is your goal?
Our application is a sip phone call handling application.(A voice response xml 
application)
The goal is to not have  call bottleneck at peak call volume.
Sometimes too many folks call at one time hit our app and calls are not handle 
correctly.

I know my application at times will reach 100 concurrent connections

  > and some times goes has high as 500 connections.

Okay.
Well I do not have actual traffic info down to the sec,
But from the application logs I know that that points in the day more than 300 
calls can come in

Okay, you need to get better information. Check out this presentation on 
Tomcat monitoring:

https://tomcat.apache.org/presentations.html#latest-monitoring-with-jmx

There is a lot in there, but I do talk about checking on the request 
processor to see how many requests are in-flight at once. You can do the 
same with your database pool.

You'll want to grab samples of those things at regular intervals to see 
how they correlate. I suspect you know when your peak times are, so 
schedule the samples to be taken during that timeframe. You could even 
sample once per second if you wanted to -- the calls are pretty inexpensive.

Should I boost minSpareThreads and maxThread values of what I plan to
use below? > Or why would we not just set very high minSpareThreads
and maxThread values like minSpareThreads =300  and maxThread=1000

This is a snippet of my server.xml

Also, am I good with setting  
protocol="org.apache.coyote.http11.Http11NioProtocol"
And then setting 

That will tell Tomcat to do HTTP2 Correct?

That's the only way to enable h2. Well... you could use Http11Nio2Protocol, 
too. NIO is the default protocol so you don't even need to add that 
specifically if you don't want to.

Back to threads.

Each thread (unless you go virtual, but that's not really production-ready IMHO at this 
point unless you have very strict circumstances where it will work great for you) takes 
up a bunch of memory, so you can't just set maxThreads=1M. Threads take "time" 
to start, but it's not really that much. If starting and stopping threads is what is 
making your application slow, than you have a very high-performance application and 
environment indeed.

Your question as stated is unanswerable.

You say you are sometimes hitting 500 connections. The default maximum number of 
connections is 1 and you are only using 500. That means you aren't being flooded, 
which is a Good Thing. (BTW: How are you measuring "how many connections" you 
have? Make sure you are measuring the right thing...

I am estimating the actual connections just based on application call logs.

Is your *current* maxThreads set to 500? If so, then your thread pool maximum 
is set to your high-water mark which seems like it should be fine. If you set 
your maxThreads to 1000 you won't get any benefit because only 500 requests are 
ever being sent at once, right?

What else does your application do?
Our application is a sip phone call handling application.(A voice response xml 
application)

For example, if you have a thread-pool max-threads of 1000 and your application 
uses an RDBMS for every request but your db connection pool size is more like 
10, then many threads waiting on a small number of connections gets you 
absolutely no benefit. You'd have to make changes elsewhere in your application 
in order to make use of those extra threads.

Similarly, if you have a big thread pool and a big db connection pool, but your 
database performs slowly, then having all that power on the application server 
doesn't really help you.

Yes our app is using a database  (we use Postres)
And yes I assume that is our bottleneck
Our tomcat context.xml defines that database maxConnction to be only 
maxTotal="20"

So if you are allowing up to 300 or 500 threads and most of them need a 
database connection, then you are really limiting yourself to more like 
20 simultaneous requests served.

You will likely need to increase that db connection pool size.

We have other apps  and that hit this same database, so we define low maxTotal  
on each  server so each server can have only limit connection access to the 
database

Well...

I am thinkingit would be best to try and NOT optimize  minSpareThreads and 
maxThreads but instead to determine what is the optimal

Re: performance tunning of Tomcat 10

2024-03-27 Thread Christopher Schultz


Rick,

On 3/27/24 07:53, Rick Noel wrote:

I was wondering if the apache foundation has any tools we can use to
fine tune Tomcat 10. Tools to deteming how to set the best heap size
for Tomcat startup and the best connection attributes of
minSpareThreads and MaxThreads.

What is your goal?


I know my application at times will reach 100 concurrent connections

> and some times goes has high as 500 connections.

Okay.


Should I boost minSpareThreads and maxThread values of what I plan to
use below? >
Or why would we not just set very high minSpareThreads and maxThread values
like minSpareThreads =300  and maxThread=1000

This is a snippet of my server.xml



   


  

Also, am I good with setting  
protocol="org.apache.coyote.http11.Http11NioProtocol"
And then setting 

That will tell Tomcat to do HTTP2 Correct?


That's the only way to enable h2. Well... you could use 
Http11Nio2Protocol, too. NIO is the default protocol so you don't even 
need to add that specifically if you don't want to.


Back to threads.

Each thread (unless you go virtual, but that's not really 
production-ready IMHO at this point unless you have very strict 
circumstances where it will work great for you) takes up a bunch of 
memory, so you can't just set maxThreads=1M. Threads take "time" to 
start, but it's not really that much. If starting and stopping threads 
is what is making your application slow, than you have a very 
high-performance application and environment indeed.


Your question as stated is unanswerable.

You say you are sometimes hitting 500 connections. The default maximum 
number of connections is 1 and you are only using 500. That means 
you aren't being flooded, which is a Good Thing. (BTW: How are you 
measuring "how many connections" you have? Make sure you are measuring 
the right thing...


Is your *current* maxThreads set to 500? If so, then your thread pool 
maximum is set to your high-water mark which seems like it should be 
fine. If you set your maxThreads to 1000 you won't get any benefit 
because only 500 requests are ever being sent at once, right?


What else does your application do?

For example, if you have a thread-pool max-threads of 1000 and your 
application uses an RDBMS for every request but your db connection pool 
size is more like 10, then many threads waiting on a small number of 
connections gets you absolutely no benefit. You'd have to make changes 
elsewhere in your application in order to make use of those extra threads.


Similarly, if you have a big thread pool and a big db connection pool, 
but your database performs slowly, then having all that power on the 
application server doesn't really help you.


So anyone trying to answer "how big should be thread pool be" really 
needs to understand the nature of your application and the other things 
happening in your environment.


Sometimes the answer is "just add more threads/CPUs/memory" and 
sometimes the answer is "re-think your application architecture".


-chris

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

Re: Tomcat Internal Architect for JSP compilation?

2024-03-26 Thread Christopher Schultz


Subodh,

On 3/26/24 06:59, Subodh Joshi wrote:

I am planning to do same now and may be we will use the property

*server.tomcat.basedir*

But this may create another issue ,it will grow the size of the folder.


What makes you say that?


Is this possible in the coming release tomcat/embedded tomcat give a
feature to delete the basedir at the tomcat restart/start and
recreate it?


This sounds more like a deployment detail and not a Tomcat-launch 
detail. Since you are using Spring Boot, why not just delete the 
directory from your own code before Tomcat launches?



One more thing is unanswered after deleting the tomcat folder why first
page clicked is throwing 500 error with ClassNotFoundException if its not
accessed before deleting the tomcat folder?


I'm sorry, I can't answer that without spending a lot of time looking at 
your environmemnt.


If you stop deleting the directory while Tomcat is running and it stops 
returning 500 responses, then I think you have solved your problem 
without discovering the absolute root-cause of the problem. But you are 
pulling the rug out from underneath a running application and expecting 
it to work without failing. I think that's not a realistic expectation. 
Tomcat relies on its local environment being stable. Dont' destabilize it.


If you absolutely need Tomcat to not-fail under thes conditions, we'd be 
happy to have you research it and provide a patch or pull-request.


-chris


On Fri, Mar 22, 2024 at 7:01 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Subodh,

On 3/22/24 01:36, Subodh Joshi wrote:

Hi Chris

Thanks for your response.

So i added below properties in application.properties file


spring.mvc.cache-control.cache-allowed=false

and then Deleted the /tmp/tomcat directory . So now when i restart the

server A.jsp only fail with 500 error (ClassNotFoundException) as this is
first page which i was trying to load, rest JSP pages working fine

without

any issue .

Why i am doing this exercise?
In our some of the deployed linux environment many clients are

complaining

about this issue , We tried to monitor who actually deleting these
/tmp/tomcat folder but still we are not able to figure it out and we are
not able to reproduce it . So i have to do reproduce it manually deleting
the /tmp/tomcat directory.


What if you don't use /tmp as your work directory location? /tmp is
supposed to be for actually temporary files. These files could live for
decades if you never changed your source .jsp files or re-deployed your
application.

-chris


On Thu, Mar 21, 2024 at 7:24 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Subudh,

On 3/21/24 07:32, Subodh Joshi wrote:

Expert,

Recently i came across a issue and i was getting no clue what was going

on

wrong with the Application.

So here is the issue , we were getting following issue in our web
application(Springboot+Embedded Tomcat) which is deployed into Linux

machine


java.lang.ClassNotFoundException:

org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp
   at
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
   at


org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129)

   at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58)
   at




org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151)

   at




org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:189)

   at




org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)

   at


org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)

   at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
   at

jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)

   at




org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205)

   at




org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)

   at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
   at




org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)

   at




org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)

   at




org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)

   at




org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)

   at




org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)

   at




org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108)

   at




org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainPr

Re: Speeding up tomcat


Alex,

On 3/25/24 13:06, Alex Hatcher wrote:

Java version: 11.0.20
Tomcat version: 9.0.59


Are you able to upgrade these? Your Tomcat is nearly 2 years old and 
your Java is ... I'm not sure how old. This will have nothing to do with 
performance. Just security and general stability.



OS Version: Windows Server 2022 Datacenter Azure Edition

Azure VM Type and Specs: D8s v3

8 CPU 32 GiB Mem

VM Generation V2

VM Architecture   x64

Location   East US Zone 1



We have a traditional client/server application from a third-party 
vendor that has a couple second delay when accessing certain items 
(tabs) in their Web UI.  The delay has been traced down to the 
webserver, which runs Tomcat.  The application and database servers

do not appear to have any significant delays.

When an item is clicked inside the web UI, a call from the web 
server is made to the app and DB server, which come back fairly

quickly.  It's at the point where data is delivered from the app
server to the web server that tomcat on the webserver CPU usage
spikes.  In reviewing the web server with procmon running, we noticed
that tomcat is reading a lot of class files during the time we are
waiting for the task to complete to render the page.   Approximately
55,000 (yes 55000) classes read each click.


Ouch.

The vendor has reviewed this and said it's nothing to worry about, 
but we cannot find any other significant task that tomcat is doing

during this wait state that a web client experiences.


Are you able to see the duration of that 55000 class file read? How have 
you observed that Tomcat is reading all those files? Once an application 
is started and humming-along, Tomcat shouldn't be reading too many class 
files at all.


Reasons I can think of for reading lots of class files:

1. Auto-reload is enabled, and your class files have timestamps in the 
future. This would basically restart your application completely every 
few seconds. I think you'd notice.


2. You have disabled caching of your  and, for some reason, 
you are constantly searching through them for something.


3. You have an application-level scan for classes which is not using 
Tomcat's (usually cached) loader to locate classes. In this case, I 
would say that your application should (a) be loading though Tomcat and 
(b) probably not scanning classes all the time :)



We have sql tracing showing microsecond response times.

Developer console in chrome shows it waiting for 1.9 (Avg) seconds per click.



We would like to get to the root cause of this slowness, whether it is the 
operating system, Azure VM, webserver or vendor application causing the issue.


Well, if your application is triggering a 55000-file scan with every 
request, that's obviously the place to start. That simply should not be 
happening. Even a fast VM, OS, web server, etc. wasting that much time 
won't be "fast". So start there.


If you are able to observe the files being read, you can probably 
arrange to have one of them refuse to be read which should produce a 
FileNotFoundException or similar in a log. Then you can see what 
component is actually triggering that file-read and try to find out what 
it's being read with every request.


I would make the vendor do this. It's what you pay them for.

-chris

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

[ANN] Apache Tomcat 10.1.20 Available


The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.20.

Apache Tomcat 10 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Applications that run on Tomcat 9 and earlier will not run on Tomcat 10 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the /webapps-javaee directory and Tomcat will 
automatically convert them to Jakarta EE and copy them to the webapps 
directory. This conversion is performed using the Apache Tomcat 
migration tool for Jakarta EE tool which is also available as a separate 
download for off-line use.


Apache Tomcat 10.1.20 is a bugfix and feature release. The notable 
changes compared to 10.1.19 include:


 - Fix regression when reloading TLS configuration and files.

 - When restoring a saved POST request after a successful FORM
   authentication, ensure that neither the URI, the query string no
   the protocol are corrupted when restoring the request body.

 - Align error handling for Writer and OutputStream. Ensure use of
   either once the response has been recycled triggers a
   NullPointerException provided that discardFacades is configured with
   the default value of true.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-10.1-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-10.cgi

Migration guides from Apache Tomcat 8.5.x and 9.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

[ANN] Apache Tomcat 8.5.100 Available


The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.100.

*This will likely be the final release of Apache Tomcat 8.5. Please see 
the EOL notice linked at the end of this message.*


Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 8.5.100 is a bugfix and feature release. The notable
changes compared to 8.5.99 include:

 - Fix regression when reloading TLS configuration and files.

 - When restoring a saved POST request after a successful FORM
   authentication, ensure that neither the URI, the query string no
   the protocol are corrupted when restoring the request body.

 - Align error handling for Writer and OutputStream. Ensure use of
   either once the response has been recycled triggers a
   NullPointerException provided that discardFacades is configured with
   the default value of true.

Please refer to the change log for the complete list of changes:
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html

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

Migration guides from Apache Tomcat 7.x and 8.0:
https://tomcat.apache.org/migration.html

Please note that Tomcat 8.5.x will reach End-of-life (EOL) on 31 March 
2024. For more information please visit 
https://tomcat.apache.org/tomcat-85-eol.html


Enjoy!

- The Apache Tomcat team

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

Re: Tomcat 9.0.87 - status 400 in css / images


DAngel,

On 3/22/24 16:14, DAngel wrote:

Tomcat 9.0.87 (and Tomcat 9.0.76)
Ubuntu 22.04 (and Red hat 8)
java 8 : openjdk version "1.8.0_382"
protocol: HTTP

I have migrated an application from tomcat 7 (7.0.76) to tomcat 9.0.76 (and
also to tomcat 9.0.87)

After upgrading to Tomcat 9.0.76, the web page is not displaying correctly
as some CSS/images are returning HTTP status 400. If we reload the browser,
it works fine.

  When this happens, the "type" of the resources is text/html .

  My error is similar to this:
https://stackoverflow.com/questions/77989064/intermittently-getting-status-400-for-js-css-images-after-upgrading-to-tomcat-9

  Any configuration I may be missing?
  Any advice to solve this error is welcome.


400 indicates that the client sent a bad request.

Are you using HTTP 1.1 or h2?

Is there a reverse-proxy between your browser and Tomcat? If so, what 
product+protocol are you using to connect the two?


Is this an environment where you could enable debug/trace logging, or is 
this production which would represent a big problem for you?


Are you able to reproduce it, even non-predictably? Meaning, if you load 
a page 10 times can you make it happen, or is it only every 100,000 page 
loads or something?


-chris

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

Re: HttpSession tracking


Robert.

On 3/22/24 14:11, Robert Turner wrote:

Thanks for figuring it out -- I will keep that in mind when I go to split
our "mega session object" up as that will impact some of the decisions for
sure.

Yeah, I guess you end up with a "dummy object" on the session as a result
-- I guess we got lucky with ours -- our handlers on the session object
call out to a "singleton" for tracking, so we probably never really thought
too much about it. So if you have an object on the session already, it pays
to just extend it and call out to the "singleton" instead (like we have).


Or, more likely, whoever implemented it discovered that you *must* have 
a singleton for this kind of thing, and didn't just get lucky. :)



Some of the listener docs do often leave me wondering how exactly some of
them work (like who creates the object instance for this thing - like for
ServletContextListener).


The container does. It's in the spec :)

If you haven't read it, it's 100% worth reading and it's quite readable. 
It was written by real humans trying to get a job done and not lawyers. 
or whatever.



Although the one  you quoted does seem to be
"clear enough" at least to me (not sure if your comments were sarcastic or
not).


Nope. I meant "I either didn't read this, or ignored what it said" 
because there really is no confusion, there.



I'm not sure it's a good design though -- you would think session
listeners would be independent of the objects on the sessions. Hopefully
there was some logic behind the original design that isn't captured in the
code docs (well, I hope there was).


I can't know why the original design was the way that it was. Would be 
interesting to be able to have an "observer" listener that doesn't have 
to be put into each and every session? Possibly. But this isn't 
particularly "expensive" to implement using the existing interfaces and 
their existing semantics.


My guess is that sessionWillPassivate and sessionDidActivate are there 
so that caches, connections to other systems, etc. can be re-created 
after a session comes back into memory for things that aren't 
appropriate to be Serializable. Maybe that's not appropriate for *every* 
session and also if you put 10 caches into a session you just implement 
each of your 10 re-creation algorithms separately.


If you had one uber-listener, it would have to understand how to 
re-create all 10 of those caches and so the fine-grained notification 
system is actually more flexible.


-chris

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

Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :


Rick,

On 3/22/24 13:33, Rick Noel wrote:

I do not want to replicate customer because that class does not
implement  serializable

I was looking for someway that the Manager would NOT try to replicate
it

This is an allow-list which is much more secure than a deny-list.

It's a regular expression, so you can feel free to get super-creative 
with the expression if you want to effectively create a deny-list with 
one item.


Honestly, this is probably some technical dept worth paying off at this 
point.


Another option would be to store the object in a wrapper in the session 
that *is* serializable but it doesn't actually try to serialize the 
object it wraps.


I did one of these ages ago for similar reasons: I didn't want to go 
change all those classes to be Serializable. Here it is:


public class TransientObjectWrapper
implements Serializable
{
private static final long serialVersionUID = -4694896879363833304L;

private transient final T _o;

public TransientObjectWrapper(T o) { _o = o; }

public T getWrappedObject() { return _o; }
}

Using this plus a craftily-written Filter, HttpServletRequestWrapper, 
and HttpSession implementation would allow you to do this kind of thing 
without any failures.


Or you could just configure Tomcat's already flexible allow-list for 
session attribute names.


-chris


-Original Message-
From: Mark Thomas 
Sent: Friday, March 22, 2024 1:27 PM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: Tomcat session replication issue - 
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :

On 22/03/2024 15:43, Rick Noel wrote:

Mark,

So if my customer object is failing to get set in the session
replication, I could add this to the config snippet?

sessionAttributeNameFilter="customer"


You set that to the attributes you DO want to replicate, not the ones you don't.

Mark



so like this?...







  
  

  

  
  
  
  


   
filter=".*\.gif|.*\.js|.*\.jpeg|.*\.jpg|.*\.png|.*\.htm|.*\.html|.*\.c

ss|.*\.txt"/>



   





Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas 
Sent: Friday, March 22, 2024 11:32 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: Tomcat session replication issue - 
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :

On 22/03/2024 15:15, Rick Noel wrote:

Is there a way to configure DeltaManager or the Cluster element so it does not 
cause my application to throw this error.

22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5]
org.apache.catalina.core.StandardWrapperValve.invoke
Servlet.service() for servlet [jsp] in context with path [##0001]
threw exception [An exception occurred processing
[/services/include/properties.jsp] at line [196]

193:
194:session.setAttribute( "format", stationFormat );
195:session.setAttribute( "employee_id", employeeId );
196:session.setAttribute( "customer", customer );
197:session.setAttribute( "customer_id", customerId );
198:session.setAttribute( "nonidentifier_call_letters", 
nonIdentifierCallLetters );
199:session.setAttribute( "call_letters", callLetters );


Stacktrace:] with root cause
  java.lang.IllegalArgumentException: setAttribute:
Non-serializable attribute [customer]


I know why the error, it is because the  customer object was never written to 
be serialiazable.
The old application I am working on has a lot of such non serialized
objects and I do not want to search out change them all to implement
serialiazable

I am hoping there is a way to configure Tomcat to just not try and
replication sessions all object which are not serialiazable


https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftomc
at.apache.org%2Ftomcat-10.1-doc%2Fconfig%2Fmanager.html=05%7C02%7
CRNoel%40westwoodone.com%7C1b723f1052ef4e59bf0808dc4a959af2%7Ce5d6709f
becf4b058cee37f5a62617c4%7C0%7C0%7C638467253633727340%7CUnknown%7CTWFp
bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
0%3D%7C0%7C%7C%7C=o5SvJv%2FM4QtRYM%2BEk18%2For7R81deb1g%2BW7N7XS
rMwuM%3D=0

Search for sessionAttributeNameFilter

Mark

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

CAUTION: This email originated from outside of the organization. Do

Re: HttpSession tracking


All,

On 3/22/24 09:59, Christopher Schultz wrote:

All,

On 3/22/24 09:33, Robert Turner wrote:

On Fri, Mar 22, 2024 at 9:28 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Robert,

On 3/21/24 15:31, Robert Turner wrote:

We receive the sessionWillPassivate and sessionDidActivate callbacks
on startup. Odd that you are not. That's how we achieve the same.

On 3/21/24 16:21, Robert Turner wrote:
Just to add a bit more information, our handler class, for better or 
for

worse, implements the following interfaces all in one class:

   implements HttpSessionBindingListener, 
HttpSessionActivationListener,

HttpSessionIdListener, HttpSessionListener, ServletContextListener


Hmm.

I'm already using HttpSessionListener and HttpSessionActivationListener
and logging every event I receive.

HttpSessionIdListener only lets you know when ids are changed, and I
actually don't care about those events. I added it, and see no change in
behavior.

HttpSessionBindingListener shouldn't do anything, here, as it will only
be called when objects are added or removed (and it only *that object*).
During activation and passivation, I wouldn't expect anything to be
added or removed.

ServletContextListener wouldn't do anything in and of itself, except
possibly get the listener started earlier. I added it and do not see any
change in behavior.



Yeah, I wasn't really suggesting adding all those listener interfaces --
more just saying that's what we did in case somehow it made a difference
for you. Certainly you shouldn't have to add them to get it to work.



We also use that same class as our "session model" object that we 
bind as

an attribute to the session itself (it's a bit of a mixed bag

historically

that I want to clean up).

And in terms of registration, we do not have any annotations on the

class,

instead we register it in web.xml (in the application WAR file) using a
standard listener entry:


  <>


Our web.xml is set at Servlet API version 3.0 (kind-of old), and we are
running against Tomcat 9.5 (and this worked on 8.5 and before as well).

Not sure if that adds anything Chris that you haven't already looked 
at.


I believe mine is set up identically to yours at this point, except for
the HttpSessionBindingListener.

I would really prefer a way to query the sessions from the app, but 
as we

know, that's not part of the current Servlet specification, or any
extensions Tomcat currently provides.


It wouldn't really be appropriate for Tomcat to provide any "extensions"
like this because it would make applications reliant on capabilities
that aren't standard. When companies do that, it's called "vendor
lock-in" and it's not a good look for ASF.



Yeah, vendor lock-in isn't great -- and I wouldn't really suggest Tomcat
doing that either; it would be better in the Servlet specification, but I
doubt, for various reasons, it would get added.

Your case is certainly odd -- I suppose you might have to resort to 
firing

up a debugger and debug build and seeing what's going on in Tomcat...(at
least you are more used to doing that on Tomcat than most of us).


So... by went ahead and loaded-up this class with *everything* - 
including putting the listener class instance into every session and I 
do indeed get "session will passivate" and "session has activated" log 
messgaes.


So I started removing things and it kept working until ... it didn't.

I'm trying to track-down exactly what difference makes it work, but it 
doesn't many any sense to me.


The StandardManager code looks like this:

   if (log.isTraceEnabled()) {
   log.trace("Loading " + n + " persisted sessions");
   }
   for (int i = 0; i < n; i++) {
   StandardSession session = getNewSession();
   session.readObjectData(ois);
   session.setManager(this);
   sessions.put(session.getIdInternal(), session);
   session.activate();
   if (!session.isValidInternal()) {
   // If session is already invalid,
   // expire session to prevent memory leak.
   session.setValid(true);
   session.expire();
   }
   sessionCounter++;
   }

and StandardSession.activate looks like this:

     public void activate() {

     // Initialize access count
     if (ACTIVITY_CHECK) {
     accessCount = new AtomicInteger();
     }

     // Notify interested session event listeners
     fireSessionEvent(SESSION_ACTIVATED_EVENT, null);

     // Notify ActivationListeners
     HttpSessionEvent event = null;
     String keys[] = keys();
     for (String key : keys) {
     Object attribute = attributes.get(key);
     if (attribute instanceof HttpSessionActivationListener) {
     if (event == null) {
     event = new HttpSessionEvent(getSession());
     }
     try {
     ((HttpSessionActivation

Re: HttpSession tracking


All,

On 3/22/24 09:33, Robert Turner wrote:

On Fri, Mar 22, 2024 at 9:28 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Robert,

On 3/21/24 15:31, Robert Turner wrote:

We receive the sessionWillPassivate and sessionDidActivate callbacks
on startup. Odd that you are not. That's how we achieve the same.

On 3/21/24 16:21, Robert Turner wrote:

Just to add a bit more information, our handler class, for better or for
worse, implements the following interfaces all in one class:

   implements HttpSessionBindingListener, HttpSessionActivationListener,
HttpSessionIdListener, HttpSessionListener, ServletContextListener


Hmm.

I'm already using HttpSessionListener and HttpSessionActivationListener
and logging every event I receive.

HttpSessionIdListener only lets you know when ids are changed, and I
actually don't care about those events. I added it, and see no change in
behavior.

HttpSessionBindingListener shouldn't do anything, here, as it will only
be called when objects are added or removed (and it only *that object*).
During activation and passivation, I wouldn't expect anything to be
added or removed.

ServletContextListener wouldn't do anything in and of itself, except
possibly get the listener started earlier. I added it and do not see any
change in behavior.



Yeah, I wasn't really suggesting adding all those listener interfaces --
more just saying that's what we did in case somehow it made a difference
for you. Certainly you shouldn't have to add them to get it to work.




We also use that same class as our "session model" object that we bind as
an attribute to the session itself (it's a bit of a mixed bag

historically

that I want to clean up).

And in terms of registration, we do not have any annotations on the

class,

instead we register it in web.xml (in the application WAR file) using a
standard listener entry:


  <>


Our web.xml is set at Servlet API version 3.0 (kind-of old), and we are
running against Tomcat 9.5 (and this worked on 8.5 and before as well).

Not sure if that adds anything Chris that you haven't already looked at.


I believe mine is set up identically to yours at this point, except for
the HttpSessionBindingListener.


I would really prefer a way to query the sessions from the app, but as we
know, that's not part of the current Servlet specification, or any
extensions Tomcat currently provides.


It wouldn't really be appropriate for Tomcat to provide any "extensions"
like this because it would make applications reliant on capabilities
that aren't standard. When companies do that, it's called "vendor
lock-in" and it's not a good look for ASF.



Yeah, vendor lock-in isn't great -- and I wouldn't really suggest Tomcat
doing that either; it would be better in the Servlet specification, but I
doubt, for various reasons, it would get added.

Your case is certainly odd -- I suppose you might have to resort to firing
up a debugger and debug build and seeing what's going on in Tomcat...(at
least you are more used to doing that on Tomcat than most of us).


So... by went ahead and loaded-up this class with *everything* - 
including putting the listener class instance into every session and I 
do indeed get "session will passivate" and "session has activated" log 
messgaes.


So I started removing things and it kept working until ... it didn't.

I'm trying to track-down exactly what difference makes it work, but it 
doesn't many any sense to me.


The StandardManager code looks like this:

  if (log.isTraceEnabled()) {
  log.trace("Loading " + n + " persisted sessions");
  }
  for (int i = 0; i < n; i++) {
  StandardSession session = getNewSession();
  session.readObjectData(ois);
  session.setManager(this);
  sessions.put(session.getIdInternal(), session);
  session.activate();
  if (!session.isValidInternal()) {
  // If session is already invalid,
  // expire session to prevent memory leak.
  session.setValid(true);
  session.expire();
  }
  sessionCounter++;
  }

and StandardSession.activate looks like this:

public void activate() {

// Initialize access count
if (ACTIVITY_CHECK) {
accessCount = new AtomicInteger();
}

// Notify interested session event listeners
fireSessionEvent(SESSION_ACTIVATED_EVENT, null);

// Notify ActivationListeners
HttpSessionEvent event = null;
String keys[] = keys();
for (String key : keys) {
Object attribute = attributes.get(key);
if (attribute instanceof HttpSessionActivationListener) {
if (event == null) {
event = new HttpSessionEvent(getSession());
}
try {
((HttpSessionActivationListener) 
attribute).sessionDidActivate(event);

} catch (Throwable t) {

Re: Memory leak in EncodingDetector?


Simon,

On 3/21/24 12:39, Simon Niederberger wrote:

Hi Chris

Personally I'd go with

XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());

allowing me to place my own JAR in common/lib if I really want to (the
only scenario I can think of is an edge-case where there's a bug in
the JVM XMLInputFactory and no upgrade path is available, so I'd place
my own JAR in common/lib).


I wonder if there really are any use-cases for applications wanting Tomcat to 
specify the XMLInputFactory *to be used for JSP*


That sounds pretty far-fetched. Our use case is simply that we deploy
frequently (several times a day) on a Tomcat 10.1 installation, and
have various reasons for not going down the Docker/container/FAT JAR
path. So, making sure we don't have memory leaks is relevant.


Done and done.

Feel free to put the fix in yourself, or grab 10.1.x from GitHub, or wit 
for Tomcat 10.1.21 to be released (10.1.20 has already been rolled and 
the voting will end shortly, so you'll have to wait for the next release).


-chris


On Thu, Mar 21, 2024 at 1:44 PM Christopher Schultz
 wrote:


Simon,

On 3/20/24 15:36, Simon Niederberger wrote:

What if you create an empty jaxp.properties file and make it available to the 
common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties) -- does that 
prevent the problem?

  >

I think that boils down to what I'm already doing with the system
property, getting to the FactoryFinder before it uses
findServiceProvider(). Haven't tried it, but I'm sure it would work.


The difference is that Tomcat can ship it as a part of the distribution,
while we shouldn't really be setting system properties like that. It
might prevent, for example, applications using their own preferred
implementation.


imho, Tomcat's EncodingDetector should init with either

XML_INPUT_FACTORY = XMLInputFactory.newDefaultFactory();

to just always use the JVM XMLInputFactory, or then

XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());

to honor it's own classloader (maybe
EncodingDetector.class.getClassLoader() is the wrong approach,
basically something getTomcatCommonClassloader())


Yeah, that's probably better than an empty properties file wrapped in a
JAR file wrapped in an enigma.

We also have the option of using the JreMemoryLeakPreventionListener for
this. There are already some XML-related protections in there, though
this one is not specifically there.

Do you have a preferred technique for fixing this? All of those
suggestions seem equally reasonable. I think I have a slight preference
for passing the JSP compiler's ClassLoader in to the factory method:

XML_INPUT_FACTORY =
  XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
  EncodingDetector.class.getClassLoader());

If you absolutey need to get your JSP compiler to have a custom
XMLInputFactory, you can copy the JSP compiler into your application and
it will use that ClassLoader instead.


What I just don't get is why there's so little online about others
havingEncodingDetector similar issues. Spring + libs like CXF or
jackson-dataformat-xml are common, both those libs have transitive
dependencies on woodstox-core. Throw in ehcache, also common, and your
webapp won't undeploy if it's the first webapp to load a JSP and thus
clinit EncodingDetector. Maybe the public has just given up on clean
undeploying.


My guess is that most people don't really care too much about clean
shutdowns of their applications. They either bring their applications up
and down along with the whole JVM (either standalone or via Docker,
etc.) or they use an embedded Tomcat where their own application hosts
Tomcat and they start/stop that.

Or they disable/ignore memory-leak detection log messages. *shrug*

I wonder if there really are any use-cases for applications wanting
Tomcat to specify the XMLInputFactory *to be used for JSP*. I suspect not.

-chris


On Wed, Mar 20, 2024 at 7:01 PM Christopher Schultz
 wrote:


Simon,

On 3/20/24 09:59, Simon Niederberger wrote:

The whole thing is caused by Maven dependencies which pull in
com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a

@ServiceProvider(XMLInputFactory.class)

annotation, where ServiceProvider is
org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
key code section, but I do find that the
javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
as registered service provider. As WstxInputFactory is not on the
common classpath (it's in WEB-INF/lib), I assume it's the webapp
classloader which is used. Below is the stacktrace where
EncodingDetector clinit happens (I defined a
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
stacktraces):

Currently I'm setting

System.setProperty("javax.xml.stream.XMLInputFactory",
"com.sun.xml.internal.stream.XMLInputFactoryImpl");
t

Re: Tomcat Internal Architect for JSP compilation?


Subodh,

On 3/22/24 01:36, Subodh Joshi wrote:

Hi Chris

Thanks for your response.

So i added below properties in application.properties file


spring.mvc.cache-control.cache-allowed=false

and then Deleted the /tmp/tomcat directory . So now when i restart the

server A.jsp only fail with 500 error (ClassNotFoundException) as this is
first page which i was trying to load, rest JSP pages working fine without
any issue .

Why i am doing this exercise?
In our some of the deployed linux environment many clients are complaining
about this issue , We tried to monitor who actually deleting these
/tmp/tomcat folder but still we are not able to figure it out and we are
not able to reproduce it . So i have to do reproduce it manually deleting
the /tmp/tomcat directory.


What if you don't use /tmp as your work directory location? /tmp is 
supposed to be for actually temporary files. These files could live for 
decades if you never changed your source .jsp files or re-deployed your 
application.


-chris


On Thu, Mar 21, 2024 at 7:24 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Subudh,

On 3/21/24 07:32, Subodh Joshi wrote:

   Expert,

Recently i came across a issue and i was getting no clue what was going

on

wrong with the Application.

So here is the issue , we were getting following issue in our web
application(Springboot+Embedded Tomcat) which is deployed into Linux

machine


java.lang.ClassNotFoundException:

org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp
  at
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
  at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129)
  at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58)
  at


org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151)

  at


org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:189)

  at


org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)

  at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
  at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
  at

jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)

  at


org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205)

  at


org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)

  at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
  at


org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)

  at


org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)

  at


org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)

  at


org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)

  at


org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)

  at


org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108)

  at


org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231)

  at


org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:365)

  at


org.springframework.security.web.access.intercept.AuthorizationFilter.doFilter(AuthorizationFilter.java:100)

  at


org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)

  at


org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126)

  at


org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:120)

  at


org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)

  at


org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:100)

  at


org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)

  at


org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:179)

  at


org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)

  at


org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)

  at


org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.ja

Re: HttpSession tracking


Robert,

On 3/21/24 15:31, Robert Turner wrote:

We receive the sessionWillPassivate and sessionDidActivate callbacks
on startup. Odd that you are not. That's how we achieve the same.

On 3/21/24 16:21, Robert Turner wrote:

Just to add a bit more information, our handler class, for better or for
worse, implements the following interfaces all in one class:

  implements HttpSessionBindingListener, HttpSessionActivationListener,
HttpSessionIdListener, HttpSessionListener, ServletContextListener


Hmm.

I'm already using HttpSessionListener and HttpSessionActivationListener 
and logging every event I receive.


HttpSessionIdListener only lets you know when ids are changed, and I 
actually don't care about those events. I added it, and see no change in 
behavior.


HttpSessionBindingListener shouldn't do anything, here, as it will only 
be called when objects are added or removed (and it only *that object*). 
During activation and passivation, I wouldn't expect anything to be 
added or removed.


ServletContextListener wouldn't do anything in and of itself, except 
possibly get the listener started earlier. I added it and do not see any 
change in behavior.



We also use that same class as our "session model" object that we bind as
an attribute to the session itself (it's a bit of a mixed bag historically
that I want to clean up).

And in terms of registration, we do not have any annotations on the class,
instead we register it in web.xml (in the application WAR file) using a
standard listener entry:


 <>


Our web.xml is set at Servlet API version 3.0 (kind-of old), and we are
running against Tomcat 9.5 (and this worked on 8.5 and before as well).

Not sure if that adds anything Chris that you haven't already looked at.


I believe mine is set up identically to yours at this point, except for 
the HttpSessionBindingListener.



I would really prefer a way to query the sessions from the app, but as we
know, that's not part of the current Servlet specification, or any
extensions Tomcat currently provides.


It wouldn't really be appropriate for Tomcat to provide any "extensions" 
like this because it would make applications reliant on capabilities 
that aren't standard. When companies do that, it's called "vendor 
lock-in" and it's not a good look for ASF.


-chris

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

HttpSession tracking


All,

After having written a solution using JMX to do something like this, I'd 
like to make it cleaner and I'm not sure it's entirely possible using 
just Servlet APIs.


I'd like to be able to track every HttpSession for the application.

for admin purposes, I'd like to be able to analyze:

1. The total number of sessions

2. The number of sessions which represent a logged-in user vs a 
crawler-session or someone who visited the home-page and got a session 
but never logged-in


3. Checking-out some specific roles of those logged-in users e.g. 
end-user, staff, admin


4. Be able to kill a session at will. For example "chris is already 
logged-in, kill his old session and let the new login remain"


I started with the obvious HttpSessionListener + 
HttpSessionActivationListener, but I tried this experiment and it didn't 
turn out how I expected:


1. Start the application and hit the front page

-> I get a call to HttpSessionListener.sessionCreated (expected)

2. Login

3. Logout

-> I get a call to HttpSessionListener.sessionDestroyed (expected)
-> I get a call to HttpSessionListener.sessionCreated (expected)
   (this second one happens because our home-page creates a session)

4. Login again

5. Stop Tomcat

-> No calls to anything I can see

6. Start Tomcat

-> No calls to anything I can see

7. Access a protected page

-> Access is allowed; I'm still logged-in.

When Tomcat shuts-down, it's saving the sessions using local 
persistence[1]. When the application comes back up, all those sessions 
are restored from the disk.


When my HttpSeessionListener starts, it's empty and doesn't know about 
any sessions. Tomcat doesn't notify it that any sessions are coming from 
that storage.


I would have expected calls to 
HttpSessionActivationListener.sessionWillPassivate and 
HttpSessionActivationListener.sessionDidActivate.


Do I have unrealistic expectations? Is there a way to capture these 
events so my in-memory session-watcher/manager is able to have an 
accurate view of what Tomcat can see?


Thanks,
-chris

[1] 
https://tomcat.apache.org/tomcat-8.5-doc/config/manager.html#Persistence_Across_Restarts


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

Re: Use JAVA/CATALINA_OPTS arguments in server.xml


Manak,

On 3/21/24 09:57, Manak Bisht wrote:

On Thu, 21 Mar 2024, 19:18 Christopher Schultz, <
ch...@christopherschultz.net> wrote:


Manak,

On 3/21/24 05:38, Manak Bisht wrote:

Thanks, Chuck!
This works for defining the port but does not work for the host.




Using either of the above throws the following error,

21-Mar-2024 15:04:58.185 SEVERE [GroupChannel-Heartbeat-1]


org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive
Unable to perform failure detection check, assuming member down.

   java.net.UnknownHostException: addr is of illegal length
at java.net.InetAddress.getByAddress(InetAddress.java:1042)
at java.net.InetAddress.getByAddress(InetAddress.java:1439)
at


org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:316)

at


org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:305)

at


org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.performForcedCheck(TcpFailureDetector.java:224)

at


org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.checkMembers(TcpFailureDetector.java:213)

at


org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.sendPing(TcpPingInterceptor.java:132)

at


org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.heartbeat(TcpPingInterceptor.java:99)

at


org.apache.catalina.tribes.group.ChannelInterceptorBase.heartbeat(ChannelInterceptorBase.java:98)

at


org.apache.catalina.tribes.group.GroupChannel.heartbeat(GroupChannel.java:154)

at


org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(GroupChannel.java:692)

What is the value of the system property "tomcat.member"?



> I have not defined its value. It works fine if I do, however, I am
> expecting it to use the default instead.

Yes, I agree. Can you run under a debugger and observe the value being 
set? Or recompile it with a log statement? I don't see much logging in 
that class, and I'm not familiar enough with the clustering code to know 
where best to enable logging to see the effective configuration.


-chris

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

Re: Tomcat Internal Architect for JSP compilation?


Subudh,

On 3/21/24 07:32, Subodh Joshi wrote:

  Expert,

Recently i came across a issue and i was getting no clue what was going on
wrong with the Application.

So here is the issue , we were getting following issue in our web
application(Springboot+Embedded Tomcat) which is deployed into Linux machine

java.lang.ClassNotFoundException:

org.apache.jsp.WEB_002dINF.jsp.ImportTab_jsp
 at
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:445)
 at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:129)
 at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:58)
 at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:151)
 at
org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:189)
 at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:410)
 at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
 at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:205)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
 at
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
 at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:110)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
 at
org.springframework.web.filter.CompositeFilter$VirtualFilterChain.doFilter(CompositeFilter.java:108)
 at
org.springframework.security.web.FilterChainProxy.lambda$doFilterInternal$3(FilterChainProxy.java:231)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:365)
 at
org.springframework.security.web.access.intercept.AuthorizationFilter.doFilter(AuthorizationFilter.java:100)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
 at
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:126)
 at
org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:120)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
 at
org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:100)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
 at
org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:179)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
 at
org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
 at
com.comptel.catalog.support.filter.OperationClientRestFilter.doFilter(OperationClientRestFilter.java:86)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)
 at
com.comptel.catalog.support.filter.JwtSecurityChainFilter.doFilter(JwtSecurityChainFilter.java:100)
 at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:374)



but how to reproduce this issue we were not able to get any clue.

But Recently i got to know how to reproduce this issue
1- Start the web-application.
2- Tomcat will create a directory under /tmp/tomcat.*/.././..
3- Now access web-application through browser.
4- But dont access all JSP pages.
5- Suppose application have A,B,C,D.jsp pages .
6- User accesses A,B.jsp only
7- Now user or any cron job deleted /tmp/tomcat directory


Don't do that.


8- Now user click on C.jsp it is throwing above given exception.
9- Now click on D.jsp it will work fine as tomcat will create /tmp/tomcat
. directory again.
10. But C.jsp which was failed with 500 error will never come upto the time
tomcat will not start.

Can someone please explain how tomcat works here and why it throws an
exception and wont allow that jsp page

Re: Use JAVA/CATALINA_OPTS arguments in server.xml


Manak,

On 3/21/24 05:38, Manak Bisht wrote:

Thanks, Chuck!
This works for defining the port but does not work for the host.

port="4000" host="${tomcat.member:-localhost}"/>
port="4000" host="${tomcat.member:-127.0.0.1}"/>


Using either of the above throws the following error,

21-Mar-2024 15:04:58.185 SEVERE [GroupChannel-Heartbeat-1] 
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive Unable to perform failure detection check, assuming member down.

  java.net.UnknownHostException: addr is of illegal length
at java.net.InetAddress.getByAddress(InetAddress.java:1042)
at java.net.InetAddress.getByAddress(InetAddress.java:1439)
at 
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:316)
at 
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.memberAlive(TcpFailureDetector.java:305)
at 
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.performForcedCheck(TcpFailureDetector.java:224)
at 
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.checkMembers(TcpFailureDetector.java:213)
at 
org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.sendPing(TcpPingInterceptor.java:132)
at 
org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.heartbeat(TcpPingInterceptor.java:99)
at 
org.apache.catalina.tribes.group.ChannelInterceptorBase.heartbeat(ChannelInterceptorBase.java:98)
at 
org.apache.catalina.tribes.group.GroupChannel.heartbeat(GroupChannel.java:154)
at 
org.apache.catalina.tribes.group.GroupChannel$HeartbeatThread.run(GroupChannel.java:692)


What is the value of the system property "tomcat.member"?

-chris

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

Re: Memory leak in EncodingDetector?

Simon,

On 3/20/24 15:36, Simon Niederberger wrote:

What if you create an empty jaxp.properties file and make it available to the
common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties) -- does that
prevent the problem?

I think that boils down to what I'm already doing with the system
property, getting to the FactoryFinder before it uses
findServiceProvider(). Haven't tried it, but I'm sure it would work.

The difference is that Tomcat can ship it as a part of the distribution,
while we shouldn't really be setting system properties like that. It
might prevent, for example, applications using their own preferred
implementation.

imho, Tomcat's EncodingDetector should init with either

XML_INPUT_FACTORY = XMLInputFactory.newDefaultFactory();

to just always use the JVM XMLInputFactory, or then

XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());

to honor it's own classloader (maybe
EncodingDetector.class.getClassLoader() is the wrong approach,
basically something getTomcatCommonClassloader())

Yeah, that's probably better than an empty properties file wrapped in a
JAR file wrapped in an enigma.

We also have the option of using the JreMemoryLeakPreventionListener for
this. There are already some XML-related protections in there, though
this one is not specifically there.

Do you have a preferred technique for fixing this? All of those
suggestions seem equally reasonable. I think I have a slight preference
for passing the JSP compiler's ClassLoader in to the factory method:

XML_INPUT_FACTORY =
XMLInputFactory.newFactory(XMLInputFactory.class.getName(),
EncodingDetector.class.getClassLoader());

If you absolutey need to get your JSP compiler to have a custom
XMLInputFactory, you can copy the JSP compiler into your application and
it will use that ClassLoader instead.

What I just don't get is why there's so little online about others
havingEncodingDetector similar issues. Spring + libs like CXF or
jackson-dataformat-xml are common, both those libs have transitive
dependencies on woodstox-core. Throw in ehcache, also common, and your
webapp won't undeploy if it's the first webapp to load a JSP and thus
clinit EncodingDetector. Maybe the public has just given up on clean
undeploying.

My guess is that most people don't really care too much about clean
shutdowns of their applications. They either bring their applications up
and down along with the whole JVM (either standalone or via Docker,
etc.) or they use an embedded Tomcat where their own application hosts
Tomcat and they start/stop that.

Or they disable/ignore memory-leak detection log messages. *shrug*

I wonder if there really are any use-cases for applications wanting
Tomcat to specify the XMLInputFactory *to be used for JSP*. I suspect not.

-chris

On Wed, Mar 20, 2024 at 7:01 PM Christopher Schultz
wrote:

Simon,

On 3/20/24 09:59, Simon Niederberger wrote:

The whole thing is caused by Maven dependencies which pull in
com.fasterxml.woodstox:woodstox-core. The WstxInputFactory has a

@ServiceProvider(XMLInputFactory.class)

annotation, where ServiceProvider is
org.ehcache.spi.service.ServiceProvider. I didn't manage to trace the
key code section, but I do find that the
javax.xml.stream.FactoryFinder then ends up finding WstxInputFactory
as registered service provider. As WstxInputFactory is not on the
common classpath (it's in WEB-INF/lib), I assume it's the webapp
classloader which is used. Below is the stacktrace where
EncodingDetector clinit happens (I defined a
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory to get
stacktraces):

Currently I'm setting

System.setProperty("javax.xml.stream.XMLInputFactory",
"com.sun.xml.internal.stream.XMLInputFactoryImpl");
to get a XMLInputFactory implementation which is on the common
loader's classpath, so the webapp can be undeployed cleanly.

So this works, right?

What if you create an empty jaxp.properties file and make it available
to the common ClassLoader (e.g. in lib/empty-jaxp.jar:/jaxp.properties)
-- does that prevent the problem?

I'm wondering if Tomcat should simply ship with an empty jaxp.properties
file to prevent this kind of thing from happening by default. If someone
wants to bundle an XMLInputFactory into Tomcat's lib/ directory and use
that, they could remove this file.

BTW that's an impressive stack trace. ;)

-chris

java.lang.RuntimeException: Stracktrace for tracking XMLInputFactory creation
at
ch.want.funnel.FunnelApp$DelegatingXMLInputFactory.(FunnelApp.java:107)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

Re: Memory leak in EncodingDetector?

2024-03-20 Thread Christopher Schultz

rPageFilter.java:117)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
 at 
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
 at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:174)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:149)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
 at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
 at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
 at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)
 at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
 at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
 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:896)
 at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1744)
 at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
 at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
 at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
 at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
 at java.base/java.lang.Thread.run(Thread.java:840)


Mühlegasse 18, 6340 Baar, Switzerland

https://www.want.ch

https://www.funnel.travel





On Tue, Mar 19, 2024 at 12:31 PM Christopher Schultz
 wrote:


Simon,

On 3/18/24 15:17, Simon Niederberger wrote:

I'm analyzing a memory leak reported by Tomcat, and have narrowed it
down to org.apache.jasper.compiler.EncodingDetector:

private static final XMLInputFactory XML_INPUT_FACTORY;
static {
  XML_INPUT_FACTORY = XMLInputFactory.newInstance();
}

This class is called by webapp code on a GET request

  at 
org.apache.jasper.compiler.EncodingDetector.(EncodingDetector.java:38)
  at 
org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:324)
  at 
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:201)
  at 
org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:128)
  at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:207)
  ...
  at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:396)
  at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
  at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)

The EncodingDetector class, if not yet loaded, will be loaded in the
common classloader, then continue by loading the XMLInputFactory using
the webapp context, and might end up with a XMLInputFactory
implementation from a webapp-provided JAR. If that happens, the webapp
can't undeploy. (In my case, woodstox WstxInputFactory registers
itself as ServiceProvider for XMLInputFactory)

For completeness: javax.xml.stream.FactoryFinder.findServiceProvider()
is called without classloader (cl = null), and has

if (cl == null) {
  //the current thread's context class loader
  serviceLoader = ServiceLoader.load(type);
} else {
  serviceLoader = ServiceLoader.load(type, cl);
}

I can't find anything online about memory leaks from webapp-provided
XMLInputFactory implementations, but this must be fairly common. Is my
understanding correct, or have I mis-configured something? (I'm mainly
wondering whether any XMLInputFactory-implementing JARs belong in
tomcat/lib, but again I'm not finding anything online confirming that)

Tomcat 10.1.19
JVM 17.0.10+7-Ubuntu-120.04.1
Ubuntu 20.04.6 LTS


I'm not sure how many web applications ship with an XMLInputSource, but
they definitely do exist. I'm fairly sure most applications won't set a
system property or ship with a stax.properties/jaxp.properties file to
override the default implementation, but of course if it's possible,
someone will eventually do it.

I'm curious: in your example, how are you declaring your

Re: PKCS#8 encryption algorithm unrecognized


Timothy,

On 3/19/24 14:18, Timothy Resh wrote:





where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below.


Is it possible for you to re-test with Tomcat 9.0.85 or later?

-chris

I have read some of the

https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask for
help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?

Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
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)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
Caused by: java.lang.IllegalArgumentException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1332)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1009)
... 13 more
Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:379)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141)
at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:108)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268)
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465)
... 19 more
15-Mar-2024 18:27:37.636 INFO [main]
org.apache.catalina.startup.Catalina.load Server initialization in [1655]
milliseconds



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

Re: [EXT]Re: 404 for j_security_check


Rick,

On 3/19/24 12:58, Rick Noel wrote:

Thanks for the help, I agree with all your statements.

I now see the  JSESSIONID cookies.

I found a bug in my code. My issue was nothing to do with Tomcat behavior.


Sorry for you, but glad it wasn't us :)

-chris


-Original Message-
From: Christopher Schultz 
Sent: Sunday, March 17, 2024 10:57 AM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: 404 for j_security_check

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

Rick,

On 3/15/24 13:49, Rick Noel wrote:


I really only want auth once

All hits to jsp pages after a successful login do not trigger the Auth process 
again.

But hits to java action class servlets do trigger the Auth process

Its  like session data is being lost for some pages but not for others


Can you watch the HTTP headers for your interaction to see what's happening? 
The browser should be sending JSESSIONID cookies with each request. If the 
server isn't sending any Set-Cookie header, the browser should leave things as 
they are.

Please note that Tomcat will send Set-Cookie when a session is created (by 
default, every JSP will create a session IIRC if you declare it to use 
sessions), plus Tomcat will rotate the session identifier as part of the 
authentication process. If you have code on the client that is storing the 
session and using it later, if your session id is being updated during 
authentication you need to make sure it gets updated everywhere the client is 
using it.


I was thinking maybe this is reason..

The Expires header specifies when content will expire, or how long content is 
"fresh."
After this time, the Portal Server will always check back with the remote 
server to see if the content has changed.
Most Web servers allow setting an absolute time to expire, a time
based on the last time that the client saw the object (last access time), or a 
time based on the last time the document changed on your server (last 
modification time).

In JSP, we can set caching to forever using the Expires header like so.

response.setDateHeader("Expires",Long.MAX_VALUE)

BUT I do not want to change my application code, I just want to tell
Tomcat 10 to stop Expiring cache so that session log in data is not
lost


No, the cache here refers to the client's resource (e.g. page, image,
etc.) cache. It has nothing to do with what's happening on the server.


My main question is
I want to know how to configure Tomcat 10 to not loose session data
that tells the user has successfully logged in


Are you properly encoding your URLs in your page like with 
HttpServletResponse.encodeURL()? If you are using cookie-based session-tracking 
it probably won't matter, but it's best practice to always do that to ensure 
your URLs are generated properly.

-chris


-Original Message-----
From: Christopher Schultz 
Sent: Friday, March 15, 2024 12:19 PM
To: users@tomcat.apache.org
Subject: [EXT]Re: 404 for j_security_check

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

Rick,

On 3/14/24 15:37, Rick Noel wrote:

After moving from tomcat 9 to tomcat 10 after a user successfully
logs in and then hits a restricted page, the login page is hit again
but on this second login hit I get 404 page not found

This is actually expected, since j_security_check is only supposed to be used 
when the container (Tomcat) interrupts a user workflow to request 
authentication.


How do I set the correct path in my  login jsp so that
j_security_check is found?

BTW  I actually am wondering why a  successful logged on user would
even be sent to the log in page again?

That's more of a question for your application than anything else.


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet


Are you doing what I call a "direct login" where you have a "login page"
that most users hit first. Like from example.com/app/ where there is no initial 
request for a protected resource? Or are your users always (1) requesting a 
protected resource then (2) Tomcat requests authentication then (3) the user is 
forwarded to the resource originally requested in (1)?




External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE lines look weird to me. 
Why are you explicitly specifying those? What part of your configuration actually requests 
authentication and authorization?

-chris

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

CAUTION: This email originated from outside of the organization. Do

Re: problems with partitioned cookies


Holger,

On 3/19/24 04:46, info@klawitter.de wrote:

dang! I missed that while checking the changelog.
Thanks for pointing out.


I'm curious about CHIPS. It's still considered experimental and, 
honestly, every web browser on the planet is poised to use the 
equivalent of "partitioned cookies" for every site, everywhere, 
regardless of the "partitioned" flag on a Set-Cookie header.


Why do you have to bother modifying your application? It seems to be 
that CHIPS will die on the vine and will never become an official standard.


In fact, it looks like it has already died:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

https://datatracker.ietf.org/doc/html/draft-cutler-httpbis-partitioned-cookies 
[ "About This Document" -> "Latest Revision of this draft" -> 404 ]


Nobody has touched the spec on GitHub in 2 years: 
https://github.com/explainers-by-googlers/CHIPS-spec


... though this documentation has been updated as recently as 5 months 
ago: https://github.com/privacycg/CHIPS


-chris


Mark Thomas wrote (at 2024-03-18 17:03 +):

On 18/03/2024 15:16, info@klawitter.de wrote:


What am I doing wrong here? (Tomcat 9.0.82)


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Search for "partitioned"

The problem is you are using Tomcat 9.0.82. Support for a default
partitioned attribute wasn't added until 9.0.85.

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: Memory leak in EncodingDetector?


Simon,

On 3/18/24 15:17, Simon Niederberger wrote:

I'm analyzing a memory leak reported by Tomcat, and have narrowed it
down to org.apache.jasper.compiler.EncodingDetector:

private static final XMLInputFactory XML_INPUT_FACTORY;
static {
 XML_INPUT_FACTORY = XMLInputFactory.newInstance();
}

This class is called by webapp code on a GET request

 at 
org.apache.jasper.compiler.EncodingDetector.(EncodingDetector.java:38)
 at 
org.apache.jasper.compiler.ParserController.determineSyntaxAndEncoding(ParserController.java:324)
 at 
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:201)
 at 
org.apache.jasper.compiler.ParserController.parseDirectives(ParserController.java:128)
 at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:207)
 ...
 at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:396)
 at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:380)
 at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:328)
 at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)

The EncodingDetector class, if not yet loaded, will be loaded in the
common classloader, then continue by loading the XMLInputFactory using
the webapp context, and might end up with a XMLInputFactory
implementation from a webapp-provided JAR. If that happens, the webapp
can't undeploy. (In my case, woodstox WstxInputFactory registers
itself as ServiceProvider for XMLInputFactory)

For completeness: javax.xml.stream.FactoryFinder.findServiceProvider()
is called without classloader (cl = null), and has

if (cl == null) {
 //the current thread's context class loader
 serviceLoader = ServiceLoader.load(type);
} else {
 serviceLoader = ServiceLoader.load(type, cl);
}

I can't find anything online about memory leaks from webapp-provided
XMLInputFactory implementations, but this must be fairly common. Is my
understanding correct, or have I mis-configured something? (I'm mainly
wondering whether any XMLInputFactory-implementing JARs belong in
tomcat/lib, but again I'm not finding anything online confirming that)

Tomcat 10.1.19
JVM 17.0.10+7-Ubuntu-120.04.1
Ubuntu 20.04.6 LTS


I'm not sure how many web applications ship with an XMLInputSource, but 
they definitely do exist. I'm fairly sure most applications won't set a 
system property or ship with a stax.properties/jaxp.properties file to 
override the default implementation, but of course if it's possible, 
someone will eventually do it.


I'm curious: in your example, how are you declaring your implementation 
class, and which implementation are you using?


Are you able to log in EncodingDetector. what the value of the 
thread's context classloader is? I would expect that it's using the 
common classloader, as you say, and that the implementation class would 
also be loaded using that same classloader.


-chris

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

Re: [EXT]Re: 404 for j_security_check

2024-03-17 Thread Christopher Schultz


Rick,

On 3/15/24 13:49, Rick Noel wrote:


I really only want auth once

All hits to jsp pages after a successful login do not trigger the Auth process 
again.

But hits to java action class servlets do trigger the Auth process

Its  like session data is being lost for some pages but not for others


Can you watch the HTTP headers for your interaction to see what's 
happening? The browser should be sending JSESSIONID cookies with each 
request. If the server isn't sending any Set-Cookie header, the browser 
should leave things as they are.


Please note that Tomcat will send Set-Cookie when a session is created 
(by default, every JSP will create a session IIRC if you declare it to 
use sessions), plus Tomcat will rotate the session identifier as part of 
the authentication process. If you have code on the client that is 
storing the session and using it later, if your session id is being 
updated during authentication you need to make sure it gets updated 
everywhere the client is using it.



I was thinking maybe this is reason..

The Expires header specifies when content will expire, or how long content is 
"fresh."
After this time, the Portal Server will always check back with the remote 
server to see if the content has changed.
Most Web servers allow setting an absolute time to expire, a time based on the 
last time that the client saw the object (last access time),
or a time based on the last time the document changed on your server (last 
modification time).

In JSP, we can set caching to forever using the Expires header like so.

response.setDateHeader("Expires",Long.MAX_VALUE)

BUT I do not want to change my application code, I just want to tell Tomcat 10 
to stop
Expiring cache so that session log in data is not lost


No, the cache here refers to the client's resource (e.g. page, image, 
etc.) cache. It has nothing to do with what's happening on the server.



My main question is
I want to know how to configure Tomcat 10 to not loose session data that tells 
the user has successfully logged in


Are you properly encoding your URLs in your page like with 
HttpServletResponse.encodeURL()? If you are using cookie-based 
session-tracking it probably won't matter, but it's best practice to 
always do that to ensure your URLs are generated properly.


-chris


-Original Message-----
From: Christopher Schultz 
Sent: Friday, March 15, 2024 12:19 PM
To: users@tomcat.apache.org
Subject: [EXT]Re: 404 for j_security_check

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

Rick,

On 3/14/24 15:37, Rick Noel wrote:

After moving from tomcat 9 to tomcat 10 after a user successfully logs
in and then hits a restricted page, the login page is hit again but on
this second login hit I get 404 page not found

This is actually expected, since j_security_check is only supposed to be used 
when the container (Tomcat) interrupts a user workflow to request 
authentication.


How do I set the correct path in my  login jsp so that
j_security_check is found?

BTW  I actually am wondering why a  successful logged on user would
even be sent to the log in page again?

That's more of a question for your application than anything else.


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet


Are you doing what I call a "direct login" where you have a "login page"
that most users hit first. Like from example.com/app/ where there is no initial 
request for a protected resource? Or are your users always (1) requesting a 
protected resource then (2) Tomcat requests authentication then (3) the user is 
forwarded to the resource originally requested in (1)?




External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE lines look weird to me. 
Why are you explicitly specifying those? What part of your configuration actually requests 
authentication and authorization?

-chris

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


-
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.o

Re: 404 for j_security_check

2024-03-15 Thread Christopher Schultz


Rick,

On 3/14/24 15:37, Rick Noel wrote:

After moving from tomcat 9 to tomcat 10 after a user successfully
logs in and then hits a restricted page, the login page is hit again
but on this second login hit I get 404 page not found
This is actually expected, since j_security_check is only supposed to be 
used when the container (Tomcat) interrupts a user workflow to request 
authentication.



How do I set the correct path in my  login jsp so that
j_security_check is found?

BTW  I actually am wondering why a  successful logged on user would
even be sent to the log in page again?

That's more of a question for your application than anything else.


My login page  is ->   /membership/login.jsp

Here is how I set the path to  j_security_check in above login.jsp



My restricted  web.xml snippet


Are you doing what I call a "direct login" where you have a "login page" 
that most users hit first. Like from example.com/app/ where there is no 
initial request for a protected resource? Or are your users always (1) 
requesting a protected resource then (2) Tomcat requests authentication 
then (3) the user is forwarded to the resource originally requested in (1)?





External
/external/*


radiovoodoo


NONE




Auth
/auth/*


radiovoodoo


NONE



FORM

/membership/login.jsp
/membership/error.jsp




Those NONE lines look weird 
to me. Why are you explicitly specifying those? What part of your 
configuration actually requests authentication and authorization?


-chris

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

Re: reloading context with manager-script

2024-03-14 Thread Christopher Schultz

Mark,

On 3/14/24 07:57, Mark Thomas wrote:

On 12/03/2024 13:47, Christopher Schultz wrote:

Greg and Mark,

On 3/12/24 05:00, Greg Huber wrote:

On 11/03/2024 18:17, Christopher Schultz wrote:

Mark,

On 3/10/24 08:49, Mark Thomas wrote:

On 10/03/2024 10:50, Greg Huber wrote:

Hello,

Using http://tomcat/manager-app/text/reload?path=/

When I reload an application (in java), I get a reply

OK - Reloaded application at context path [/]

but when the application is not present I get this reply:

FAIL - No context exists named []

Is it intentional that the fail shows the ascii code rather than 
the slash like on the OK?

Yes.

If the provided context exists then we know that the name is HTML 
safe since all valid context names are HTML safe. In this case 
there is no escaping.

If the context does not exist then the provided content name may 
not be HTML safe (it could be a deliberate XSS attempt) hence it is 
escaped.

What is the Content-Type of the response? The URL implies that it's 
a text interface, not HTML.

 >
 > Running it on the browser I get
 >
 > Content-Type : text/plain;charset=utf-8

Yeah, that's what I was expecting.

I think HTML escaping is not appropriate, here.

Agreed. The challenge is that you don't have the context to determine if 
the request originates from the HTMLManagerServlet.

It may be possible to refactor the escaping so it happens in 
HTMLManagerServlet instead.

Okay, that's fair.

We also might be able to sniff the content-type from the code generating 
the response to decide whether or not to HTML-escape.

-chris

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

Re: Tomcat 9 returning 404 for audio files

2024-03-14 Thread Christopher Schultz


Sam,

On 3/13/24 22:34, Sam wrote:

Thank you so much!

Finally issue is resolved.

Regards!

On Tue, Mar 12, 2024, 11:43 p.m. Anson Cheung 
wrote:


ok,it's a problem caused by tomcat cache. You need to disable it. Please
refer to

https://serverfault.com/questions/40205/how-do-i-disable-tomcat-caching-im-having-weird-static-file-problems

On Wed, Mar 13, 2024 at 3:46 AM Chuck Caldarale  wrote:




On Mar 12, 2024, at 13:15, Sam  wrote:

As I said earlier, 404 error is only returned 1st time.

Subsequent requests work fine.



What triggers the creation of the audio file? Is it possible that the
trigger creates a file-not-found state in the Tomcat resource cache, and
that’s what is returned the first time?


If disabling your cache "[finally resolved your issue]" then everyone 
who was asking if you were triggering a file-read through Tomcat was 
correct, even though you kept telling them they were wrong.


-chris

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

Re: reloading context with manager-script

2024-03-12 Thread Christopher Schultz

Greg and Mark,

On 3/12/24 05:00, Greg Huber wrote:

On 11/03/2024 18:17, Christopher Schultz wrote:

Mark,

On 3/10/24 08:49, Mark Thomas wrote:

On 10/03/2024 10:50, Greg Huber wrote:

Hello,

Using http://tomcat/manager-app/text/reload?path=/

When I reload an application (in java), I get a reply

OK - Reloaded application at context path [/]

but when the application is not present I get this reply:

FAIL - No context exists named []

Is it intentional that the fail shows the ascii code rather than the 
slash like on the OK?

Yes.

If the provided context exists then we know that the name is HTML 
safe since all valid context names are HTML safe. In this case there 
is no escaping.

If the context does not exist then the provided content name may not 
be HTML safe (it could be a deliberate XSS attempt) hence it is escaped.

What is the Content-Type of the response? The URL implies that it's a 
text interface, not HTML.

>
> Running it on the browser I get
>
> Content-Type : text/plain;charset=utf-8

Yeah, that's what I was expecting.

I think HTML escaping is not appropriate, here.

-chris

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

Re: When does Tomcat add and remove threads?

2024-03-12 Thread Christopher Schultz

John,

On 3/11/24 18:14, john.e.gr...@wellsfargo.com.INVALID wrote:

From: Christopher Schultz 
Sent: Monday, March 11, 2024 5:09 PM

>

On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:

I am using Tomcat 9.x.

When does Tomcat add and remove threads from its internal thread
pool?  I'm talking about the threads with names like
http-nio-8080-exec-1.  It appears the thread pool is Tomcat's own
ThreadPoolExecutor but I don't see the exact behavior documented.
I'm familiar with how java.util.concurrent does it, but it looks like
Tomcat's version is a little different.

>>

Are you looking for a technical explanation with code references,
or a plain-English description of when threads are created and
added? >
Mostly plain English like the j.u.c. ThreadPoolExecutor Java doc 
has. What happens when all core threads are in use?  When do tasks go

on the queue?  When does core thread + 1 get added?  When do threads
get removed?
Tomcat will create thread pools under two separate circumstances. They 
are related, but behave somewhat differently.

First, if you declare an  in your server.xml, then a thread 
pool will be created. You can control the number of threads and their 
retention policy such as "keep X spare threads around" and "retire 
threads after N seconds without being used."

Second, if you declare a  without specifying an "executor", a 
thread pool will be configured for you but you don't really have control 
over it because all those nice configuration options for an  
are not available on the . If you want to control those 
settings, use a  linked with an . To be clear, if 
you declare a  without an "executor" attribute, your thread 
pool will be of a fixed size and threads will never be released. (I 
think the thread pool starts small and grows but will never shrink.)

An  is implemented in the StandardThreadExecutor and 
ThreadPoolExecutor classes, which I believe were adaptations of classes 
from java.util.concurrent introduced into Tomcat before 
java.util.concurrent was actually available -- which is why it wasn't 
used directly in Tomcat. (NB: The ThreadPoolExecutor class in Tomcat 
contains an "@author Doug Lea" tag. The Tomcat source is licensed under 
AL2, the JDK source is licensed under GPL2, but the original was 
released by Doug Lea into the public domain under a CC0 1.0 Deed license.)

The re-sizing occurs in the ThreadPoolExecutor class if you'd like to 
read it. It is not entirely straightforward. You could start by reading 
the code for the runWorker(Worker w) method where, at the end, 
processWorkerExit is called.

But since Tomcat's ThreadPoolExecutor is basically Java's 
ThreadPoolExecutor, they work the same.

-chris

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

Re: When does Tomcat add and remove threads?


John,

On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:

I am using Tomcat 9.x.

When does Tomcat add and remove threads from its internal thread
pool?  I'm talking about the threads with names like
http-nio-8080-exec-1.  It appears the thread pool is Tomcat's own
ThreadPoolExecutor but I don't see the exact behavior documented.
I'm familiar with how java.util.concurrent does it, but it looks like
Tomcat's version is a little different.
Are you looking for a technical explanation with code references, or a 
plain-English description of when threads are created and added?


-chris

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

Re: how to reload SSL certificates without restarting Tomcat


Jerry,

On 3/11/24 14:51, Jerry Lin wrote:

Hi Chris,

There is also this:

https://tomcat.apache.org/presentations.html#latest-lets-encrypt

It's very LE-focused, but it shows you how to programmatically trigger a
reload.



Thanks for your presentation and script. We are using Let's Encrypt, so
your material is quite relevant.


If I were to present that material today, it would be a lot shorter. In 
fact, I was asked last-minute to fill-in for a missing speaker in 
Halifax and I updated that presentation a bit and made it more of a 
conversation with the audience.


I hadn't included anything about the automatic-update feature Tomcat has 
added since the previous staging of that presentation and afterwards I 
went in and removed something like 40% of the material in the presentation.


So it's all perfectly valid, but it's even easier to use LE with Tomcat, 
now.


-chris

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

Re: Tomcat 9 returning 404 for audio files


Sam,

On 3/11/24 13:04, Sam wrote:

On the server side, I'm checking that file exists before returning the file
path to the browser. We are also dynamically creating pdf files this way
and no issues with accessing them.


How are you checking to see if the file exists? It's possible that your 
check-for-existance triggers the "not found" in Tomcat's  
instance, then you create your file on-disk and return the path to the 
browser, then the browser requests the path and gets the cached "not found".



I found something interesting:
https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From this
link:
*Resources are cached by default.*

I'll try with *Cache-Control* request header and see if it helps!


This isn't likey to be the problem. I think the cache you are fighting 
is the one Tomcat maintains for "resources" which is how Tomcat loads 
things from ... well, everywhere. Not caching things like "not found" 
makes things go very slowly.


-chris


On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:


On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is
created? The resources implementation can cache "not found" results for
a short period of time.

You might want to test the code with a simple text file to determine
whether file type is a factor (which seems unlikely but you never know).

Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns

404 error but if reloading the page, audio file is loaded properly and

no

error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working

without

any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers

and

data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


  
bottom:0;"



 


   
src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"

type="audio/mpeg" >
 
  

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



-
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: [OT] Tomcat SMPT TLS1.2


Brandie,

(Marking this [OT] as it's not really a Tomcat question.)

On 3/11/24 12:34, Brandie Nickey wrote:

I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have
been trying to find out where to configure outbound smtp messages to
use only TLS1.2.  I've found plenty of info on the https using TLS1.2
and have configured that just fine in server.xml file and in the Java
tab of the tomcatw.exe file, but that doesn't seem to be applying to
the emails outgoing from the webapp.   Anyone have any ideas? (Also
upgrading is not an option as this tomcat/java combo is the only one
supported by the vendor for our webapp version).


Assuming that you are using JavaMail for your email, I assembled a whole
lot of properties that can be fed to JavaMail when making SMTP
connections and documented them here:

https://github.com/ChristopherSchultz/java-email/blob/main/src/main/resources/mail.properties

It's been a very long time since I looked at that code, but if you look 
at the code for Mailer.java in that project, you should be able to see 
how the properties are used to establish a Transport (aka connection) 
and Session.


Most of the properties are passed-through to 
Session.getDefaultInstance(Properties).


-chris

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

Re: how to reload SSL certificates without restarting Tomcat


Jerry,

On 3/10/24 16:00, Jerry Lin wrote:

Hi Chuck,

Presumably, you mean “not behind https", since “Apache” refers to the

organization that develops and maintains a plethora of software products.



Yes, “not behind https" (I meant not behind an Apache HTTP server)



you can configure the TLS config listener:


https://tomcat.apache.org/tomcat-10.1-doc/config/listeners.html#TLS_configuration_reload_listener_-_org.apache.catalina.security.TLSCertificateReloadListener



Great, thanks! This is what I was looking for.


There is also this:
https://tomcat.apache.org/presentations.html#latest-lets-encrypt

It's very LE-focused, but it shows you how to programmatically trigger a 
reload.


Chuck's reference to the auto-reloading is even better if you don't mind 
the background process checking for you, instead of 
proactively-triggering the reload.


-chris

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

Re: reloading context with manager-script


Mark,

On 3/10/24 08:49, Mark Thomas wrote:

On 10/03/2024 10:50, Greg Huber wrote:

Hello,

Using http://tomcat/manager-app/text/reload?path=/

When I reload an application (in java), I get a reply

OK - Reloaded application at context path [/]

but when the application is not present I get this reply:

FAIL - No context exists named []

Is it intentional that the fail shows the ascii code rather than the 
slash like on the OK?


Yes.

If the provided context exists then we know that the name is HTML safe 
since all valid context names are HTML safe. In this case there is no 
escaping.


If the context does not exist then the provided content name may not be 
HTML safe (it could be a deliberate XSS attempt) hence it is escaped.


What is the Content-Type of the response? The URL implies that it's a 
text interface, not HTML.


-chris

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

Re: SpringBoot Embedded Tomcat Server RateLimitFilter

2024-03-04 Thread Christopher Schultz


Ved,

On 2/28/24 00:56, Ved wrote:

Hi,
I am using spring boot and wanted to use Rate Limit. I can find it in
package org.apache.catalina.filters; //in embedded tomcat

But this RateLimitFilter is never called. I want to understand when this
filter is called and how I can customize it.


Have you configured the RateLimitFilter at all? If so, how? It's not 
enabled by default.


-chris

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

Re: How to properly enable logging in "org.apache.catalina.core.StandardContext"

2024-03-04 Thread Christopher Schultz


David,

On 2/29/24 13:21, David Karr wrote:

In our SpringBoot services, we sometimes run into situations where we get
an exception like this:

org.springframework.context.ApplicationContextException: Unable to start
web server; nested exception is
org.springframework.boot.web.server.WebServerException: Unable to start
embedded Tomcat


It doesn't provide any meaningful root cause.  I've googled how to get more
verbosity from this, but the results are so varied and often conflicting,
and I've never found a strategy that works. It appears that the logger used
in Catalina is not directly compatible with logback, or I'm not figuring
out the correct logger name to use.

I was finally able to figure out why this particular failure was happening,
but that was by carefully stepping through the code and finding new
breakpoints to drill down further. I saw references to the "juli" framework
for logging, which I had seen mentioned in the threads that talk about
getting these logs, but I was never able to get it to work.

As opposed to using my serious debugging skills, I'd like to figure out how
to simply increase the Tomcat logging levels so we can get better
information.



Is this helpful?

https://tomcat.apache.org/tomcat-9.0-doc/logging.html

-chris

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

Re: Core Dump File Generation

2024-03-04 Thread Christopher Schultz


Mohit,

On 2/28/24 04:39, Chaudhary, Mohit wrote:

I am talking about java core dump file which is generating on tomcat/bin path 
and the OS is RHEL 6.


There is no such thing as a "java core dump file".

What is the name of the file? Something like hs_err_*? or is this 
something in catalina.out?


If it's an hs_err_* file then your JVM is crashing. The good news about 
those files is they tell you exactly what is crashing. If you don't mind 
posting the top of that file including the native stack, etc. maybe we 
can help.


That version of Java is really really old. Even if you are stuck on Java 
1.8 like a lot of people who are too scared to upgrade, you should be 
able to get a much later version of Java from e.g. Eclipse Adoptium / 
Temurin. Perhaps there was a JVM bug that has been fixed?


-chris


-Original Message-
From: Simon Matter 
Sent: Wednesday, February 28, 2024 3:03 PM
To: Tomcat Users List 
Subject: Re: Core Dump File Generation

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

Hi Mohit,


Hi All,

We are facing issues on tomcat. Core dump file generating very
frequent twice to thrice in a month and core file size would be 13GB
to 15GB every time .Whenever this issue is happening tomcat services
stopped


I'm a bit confused, are you talking about a UNIX style core file here or some 
kind of dump from Java?

If it's a UNIX style core file then the culprit may be Java and not Tomcat
- because Java should never ever dump a core file if it's running without 
errors.

Regards,
Simon


-
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: Need help for a problem on migrating from Tomcat-8 to Tomcat-9

2024-02-27 Thread Christopher Schultz


Rajib,

On 2/26/24 23:43, Saha, Rajib wrote:

Hi Mark,

Thanks for your explanation and suggestion.
For my use case, I have used the below option and its working fine.
=
--ServiceUser="LocalSystem"
=

Thank you very much for showing the way. 


I'm glad you got your service working.

But.

Your next task should be to determine why you need to run your service 
as (essentially) local-Administrator and fix it so you don't have to. 
Anyone who is able to take control of your application will have 
complete control of the local machine.


This is a huge red-flag from a security standpoint.

-chris


-Original Message-
From: Mark Thomas 
Sent: 26 February 2024 14:23
To: users@tomcat.apache.org
Subject: Re: Need help for a problem on migrating from Tomcat-8 to Tomcat-9

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

On 26/02/2024 06:11, Saha, Rajib wrote:

Hi Experts,

In our product, we are using Tomcat [OriginalFileName:  prunsrv.exe] for 
creating a service[Say, Service-A]. It's a huge product running in market for 
last 20 years.
We are in progress of moving from Tomcat-8 to tomcat-9.

When we are creating the Service-A with Tomcat-8 [tomcat8.exe]. In "Services" desktop app, we can 
see the service is created with "Local System" in "Log On as".
When we are creating the Service-A with Tomcat-9 [tomcat9.exe]. in "Services" desktop app, we can 
see the service is created with "Local service" in "Log On as".

Looks like "Local service" has less power than "Local System".
Due to it, Service-A created with Tomcat-9 failing for several operation inside 
product.


That should be a security concern. Local System is broadly equivalent to
local administrator. You generally don't want to be running Tomcat under
Local System.


Can somebody suggest, how we can create a service with tomcat-9, with the privilege of 
"Local System"?


Have you looked at the documentation?

https://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html

Look for "--ServiceUser"

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

Any way to look-up a session from application?

2024-02-27 Thread Christopher Schultz


All,

I'm looking at building some administrative tools into my application, 
and I'd like to be able to inspect user sessions for certain attributes.


I know that I can use JMX to make calls to the (session) Manager, but it 
looks like the only things really exposed are:


String[] listSessionIds()
String getSessionAttribute(String sessionId, String attributeName)

There are other operations available but they aren't related to what I'd 
like to do: get a reference to the Session object itself, so I can get 
attributes as their *actual* types and not converted to a String.


Is that possible using existing Tomcat-provided tools?

Another option would be to register an HttpSessionListener / 
HttpSessionActivationListener and keep track of all the events so I have 
my own "private" set of references to all of those sessions.


Is there a way to do this without writing my own session-tracking code? 
The old HttpSessionContext interface has been deprecated for ages and 
implementations are required to be no-ops.


-chris

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

Re: TOMCAT CERTIFICATE RENEWAL

2024-02-23 Thread Christopher Schultz


Prabu,

On 2/19/24 02:40, Ganesan, Prabu wrote:

Thanks for your information - its jks file do we have any specific
command to pass them for renew the certificate?
If you aren't sure how to do this, maybe you aren't the right person to 
try to do this.


-chris


_
PrabuGanesan
Consultant|MS-Nordics
capgemini India Pvt. Ltd. | Bangalore
Contact: +91 8526554535
Email: prabhu.c.gane...@capgemini.com

www.capgemini.com
People matter, results count.
__
Connect with Capgemini:

  
Please consider the environment and do not print this email unless absolutely necessary.

Capgemini encourages environmental awareness.

-Original Message-
From: Thomas Hoffmann (Speed4Trade GmbH) 

Sent: Monday, February 19, 2024 12:49 PM
To: Tomcat Users List 
Subject: AW: TOMCAT CERTIFICATE RENEWAL

**This mail has been sent from an external source. Do not reply to it, or 
open any links/attachments unless you are sure of the sender's identity.**

Hello Ganesan,


Von: Ganesan, Prabu 
Gesendet: Montag, 19. Februar 2024 08:07
An: Tomcat Users List 
Betreff: TOMCAT CERTIFICATE RENEWAL
Priorität: Hoch

  Hi Guys,
  How to renew the certificate in Tomcat Can anyone provide with steps as we 
have Our tomcat certificate is about to expire in Next week, Anybody can help 
with  renew steps:
  Tomcat version : 8.5.5.0
Thanks & Regards,
_
PrabuGanesan
Consultant|MS-Nordics
capgemini India Pvt. Ltd. | Bangalore
Contact: +91 8526554535


Take a look at the server.xml and inspect the https connector.
There should be a reference to the key file and certificate-file.
Depending on the used format (pem, jks etc) you need to update these files.

Greetings,
Thomas

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


This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.


-
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: ConnectionPool JDBC vs. DBCP

2024-02-16 Thread Christopher Schultz


Andreas,

On 2/16/24 02:21, Döscher, Andreas (ESI) wrote:

Moin,
in the docpage https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool.html it says


The JDBC Connection Pool org.apache.tomcat.jdbc.pool is a replacement or an 
alternative to the Apache Commons DBCP connection pool.

So why do we need a new connection pool?

Here are a few of the reasons:

Commons DBCP 1.x is single threaded. In order to be thread safe Commons 
locks the entire pool for short periods during both object allocation and 
object return. Note that this does not apply to Commons DBCP 2.x.

[...snip...]

I thought that Tomcat uses DBCP 2.x per default, is this document still 
relevant or is it outdated?


Recent versions of Tomcat do indeed use DBCP2.

You are reading the documentation for the pool itself, which is 
justifying the reason it was developed in the first place, back when 
Tomcat shipped with DBCP1. DBCP2 was created for many of the same 
reasons tomcat-pool was created, just on different schedules.


This document could be updated to make it clear that the comparison of 
tomcat-pool against DBCP1 is a historical comparison, and that Tomcat 
now uses DBCP2 by default which does not suffer from the same problems 
tomcat-pool was designed to address.


There are some significant architectural and feature differences between 
DBCP2 and tomcat-pool which is why we haven't shut the sub-project down.


-chris

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

Re: Tomcat/Java starts using too much memory and not by the heap or non-heap memory

2024-02-16 Thread Christopher Schultz


Chuck and Brian,

On 2/15/24 10:53, Chuck Caldarale wrote:



On Feb 15, 2024, at 09:04, Brian Braun  wrote:

I discovered the JCMD command to perform the native memory tracking. When
running it, after 3-4 days since I started Tomcat, I found out that the
compiler was using hundreds of MB and that is exactly why the Tomcat
process starts abusing the memory! This is what I saw when executing "sudo jcmd 
 VM.native_memory scale=MB":

Compiler (reserved=3D340MB, commited=3D340MB)
(arena=3D340MB #10)

Then I discovered the Jemalloc tool (http://jemalloc.net 
) and its jeprof
tool, so I started launching Tomcat using it. Then, after 3-4 days after
Tomcat starts I was able to create some GIF images from the dumps that
Jemalloc creates. The GIF files show the problem: 75-90% of the memory is
being used by some weird activity in the compiler! It seems that something
called "The C2 compile/JIT compiler" starts doing something after 3-4 days,
and that creates the leak. Why after 3-4 days and not sooner? I don't know.



There have been numerous bugs filed with OpenJDK for C2 memory leaks over the 
past few years, mostly related to recompiling certain methods. The C2 compiler 
kicks in when fully optimizing methods, and it may recompile methods after 
internal instrumentation shows that additional performance can be obtained by 
doing so.



I am attaching the GIF in this email.



Attachments are stripped on this mailing list.


:(

I'd love to see these.


Does anybody know how to deal with this?



You could disable the C2 compiler temporarily, and just let C1 handle your 
code. Performance will be somewhat degraded, but may well still be acceptable. 
Add the following to the JVM options when you launch Tomcat:

-XX:TieredStopAtLevel=1



By the way, I'm running my website using Tomcat 9.0.58, Java
"11.0.21+9-post-Ubuntu-0ubuntu122.04", Ubuntu 22.04.03. And I am developing
using Eclipse and compiling my WAR file with a "Compiler compliance
level:11".



You could try a more recent JVM version; JDK 11 was first released over 5 years 
ago, although it is still being maintained.


There is an 11.0.22 -- just a patch-release away from what you appear to 
have. I'm not sure if it's offered through your package-manager, but you 
could give it a try directly from e.g. Eclipse Adoptium / Temurin.


Honestly, if your code runs on Java 11, it's very likely that it will 
run just fine on Java 17 or Java 21. Debian has packages for Java 17 for 
sure, so I suspect Ubuntu will have them available as well.


Debian-based distros will allow you to install and run multiple 
JDKs/JREs in parallel, so you can install Java 17 (or 21) without 
cutting-off access to Java 11 if you still want it.


-chris

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

Re: [OT] Tomcat not syncing existing sessions on restart


Manak,

On 2/12/24 10:33, Manak Bisht wrote:

Chris,

On Mon, 12 Feb 2024, 20:52 Christopher Schultz, <
ch...@christopherschultz.net> wrote:


I wouldn't refuse to configure, since anyone using
0.0.0.0 with /separate/ hosts wouldn't experience this problem.



I am using separate hosts (two docker containers on two different machines)
in my main deployment. I just reproduced the problem on the same host to
rule out network issues.


Thanks for the clarification. For some reason, I thought this was two 
Docker containers on the same host.


-chris

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

Re: Tomcat Instance unable to connect to DB with TCPS


Michael,

On 2/8/24 21:54, Kebret, Michael wrote:

Tomcat version 9.0.83 running on Linux  redhat 7 java 11.0.20.

When changing the protocol from TCP to TCPS in Catalina.properties
and in server.xml we have attribute truststorePassword= (tested with
both cleartext and encrypted) password connection is refused to the
DB and get the below exceptions. However, when we add
-Djavax.net.ssl.trustStorePassword=cleartext to setenv.sh the
connection is made successfully. Wanted to see if anyone has faced
something similar or have any suggestions on how I can get TCPS
working without having to use -D option in setenv.sh >
java.sql.SQLException: Unable to start the Universal Connection Pool:
oracle.ucp.UniversalConnectionPoolException: Cannot get Connection
from Datasource: java.sql.SQLRecoverableException: IO Error: The
Network Adapter could not establish the connection
You probably do not want to set a JVM-wide default trust store password. 
Instead, you probably want to use your JDBC connection URL to pass the 
trust store location and password directly to the driver.


Something like

jdbc:oracle:thin:@//[HOST][:PORT]/SERVICE?truststore=/etc/myapp/db.p12=changeit

Have a look at 
https://docs.oracle.com/cd/E13222_01/wls/docs81/jdbc_drivers/oracle.html#1066413 
for inspiration. I'm not sure if this is the driver you are using or not.


I don't see anything in there that applies. :(

Perhaps Oracle's driver really does require that you use JVM-wide trust 
store and password? Super-yuck.


-chris

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

Re: [OT] Tomcat not syncing existing sessions on restart


Mark,

On 2/9/24 06:14, Mark Thomas wrote:
With the Receiver using address="0.0.0.0" I see the same issues you do. 
I'm not yet convinced that is a bug.


If this is known to essentially always not-work... should we log 
something at startup? I wouldn't refuse to configure, since anyone using 
0.0.0.0 with /separate/ hosts wouldn't experience this problem.


-chris

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

Re: Persistent Manager Implementation Question