from:"Mark Thomas"

Re: Using HTTP 1.1 over a configured HTTP2 Connector

2024-10-01 Thread Mark Thomas


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

Dear Tomcat Team,

I hope this message finds you well.

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


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


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

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


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


Can you be more precise about what the problem is?

Mark




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




 

   

 

 

 


Thank you so much for your help.



Thanks and Regards,
Anurag Sharma




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

Re: net::ERR_HTTP2_PROTOCOL_ERROR with 10.1.30

2024-09-30 Thread Mark Thomas


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

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


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



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

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


Does setting discardRequestsAndResponses="true" help at all?

Mark




Thanks a lot,Ahmed Ashour



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

Re: Setting Transfer-Encoding: chunked

2024-09-30 Thread Mark Thomas


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

Hello,

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


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


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


Mark


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

Re: Elapsed Time incorrect for HTTP/2.0?

2024-09-27 Thread Mark Thomas


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



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

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

Hi,

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

Is that expected or a bug?


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


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


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


Mark


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

Re: Website inconsistency

2024-09-26 Thread Mark Thomas


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

Hi Folks,

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

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


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


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


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


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

Mark


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

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

2024-09-24 Thread Mark Thomas


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


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

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

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


That is an error triggered when stopping the web application.

I suggest the following.

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

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


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


Mark

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

Re: Elapsed Time incorrect for HTTP/2.0?

2024-09-24 Thread Mark Thomas


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

Hi,

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

Is that expected or a bug?


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


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


Mark




I assume this is because of http2 multiplexing maybe?

Tomcat version is 10.1.30

Mfg
Thomas



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

Re: tomcat query

2024-09-23 Thread Mark Thomas


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

Hi Team,

I Have few queries

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

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


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

Look for "Advanced Configuration - Multiple Tomcat Instances"

CATALINA_BASE points to your instance.

CAATALINA_HOME points to the binaries.

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

Mark


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

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

2024-09-23 Thread Mark Thomas


CVE-2024-38286 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

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

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


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

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


History:
2024-07-03 Original advisory

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

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

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

2024-09-23 Thread Mark Thomas


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

Severity: Moderate

Vendor: The Apache Software Foundation

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

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


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

History:
2024-09-23 Original advisory

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

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

Re: Tld Scanner and tomcat-coyote-ffm

2024-09-21 Thread Mark Thomas


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

Hello,

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

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


It is as of 10.1.29.

Mark


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

Re: Error migrating to Tomcat 10.1

2024-09-19 Thread Mark Thomas


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

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


 NavigationServlet
 *.navigation
   

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

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


Yes.



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

> > Thoughts?

Unlikely related given the error you are seeing.

Mark




Thanks


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

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

I am using the latest Tomcat 10.1

Java 17

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

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


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

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

Mark




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

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

This is my server.xml file:

 









  

  




  



Error in the jk.log on apache running mod_jk:

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

Re: Error migrating to Tomcat 10.1

2024-09-19 Thread Mark Thomas


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

I am using the latest Tomcat 10.1

Java 17

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

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


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


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


Mark




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

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

This is my server.xml file:




   
   
   
   
   

   

 

 

   

   
 
   


Error in the jk.log on apache running mod_jk:

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


Thanks,

Lance Campbell




-
To unsubs

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

2024-09-17 Thread Mark Thomas


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

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


HTTP headers use CRLF as a line terminator.

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


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


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


Mark



Regards,
Manjosh Ramesh

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


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


Yes.


Could you please share the bug id for this change?


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

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

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

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

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


Because the older tomcat allows this type of request.


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


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


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


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


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

Mark



Regards,Manjosh Ramesh

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


Chuck Caldarale  changed:

             What    |Removed                    |Added

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

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




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

   



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

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

2024-09-17 Thread Mark Thomas


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


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


Yes.


Could you please share the bug id for this change?


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


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


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


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


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



Because the older tomcat allows this type of request.


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



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


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



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


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


Mark



Regards,Manjosh Ramesh

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


Chuck Caldarale  changed:

           What    |Removed                    |Added

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

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




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

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

2024-09-16 Thread Mark Thomas


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

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

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M26 is a milestone release of the 11.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 11.0.x so that they may provide feedback. The notable
changes compared to 11.0.0-M25 include:

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

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

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

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

Enjoy!

- The Apache Tomcat team

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

Re: Question about upgrading tomcat-embed-core from 10.1.20 to 10.1.25

2024-09-15 Thread Mark Thomas





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

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


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


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

Mark


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

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

2024-09-13 Thread Mark Thomas

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


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

The regression can be worked around by setting:

discardRequestsAndResponses="true"

on the UpgradeProtocol element for HTTP/2.

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


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

- The Apache Tomcat team

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

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

2024-09-11 Thread Mark Thomas


Michael,

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

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


Mark





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

Hello,

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

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

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

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

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

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

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

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

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

Thank you,
Mike

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



Information Classification: General




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

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

2024-09-10 Thread Mark Thomas


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

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

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M25 is a milestone release of the 11.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 11.0.x so that they may provide feedback. The notable
changes compared to 11.0.0-M24 include:

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

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

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

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

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

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

Enjoy!

- The Apache Tomcat team

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

Re: Tomcat 10.1 and context.xml

2024-09-10 Thread Mark Thomas


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

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

It's contents are





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


Support is unchanged. From the 9.0.x docs:

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


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


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


Mark

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

Re: Nothing but 404 errors

2024-09-05 Thread Mark Thomas


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

Doh!  I have resolved it.

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

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


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


Mark


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

Re: JNDI connection pool in Tomcat 10.1

2024-09-05 Thread Mark Thomas


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

Hello

Tomcat 10.1, Java 17, MySQL Connector 9.0

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

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

  


Context.xml

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

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


That looks reasonable.


Server.xml

   



 

 


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





ResourceLink name="jdbc/CodereaperDB"

 global="jdbc/CodereaperDB"

 auth="Container"

 type="javax.sql.DataSource" />

   



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



Enable debug logging for the JNDI lookup with:

org.apache.naming.level = ALL

in $CATALINA_BASE/conf/logging.properties

The full path to that DataSource should be:

java:comp/env/jdbc/CodereaperDB


Mark


  


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 ... 88 more

Related cause:

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

  


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

My Spring bean is below

 

 



  

  





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

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

2024-09-03 Thread Mark Thomas


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

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

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

  


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

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

  


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


Possibly an issue with the Eclipse environment?

mvn clean verify

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


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


Mark




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

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

  


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

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

  

  


Output from Maven verify is below

Not sure what to do about it

  


Scanning for projects...

[INFO]

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

[m


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

[INFO]   from pom.xml

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

[INFO]
[1m[
m

[INFO] [1;31mBUILD FAILURE[m

[INFO]
[1m[
m

[INFO] Total time:  0.647 s

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

[INFO]
[1m[
m

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

[ERROR]

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

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

[ERROR]

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

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

  

  





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

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

2024-09-03 Thread Mark Thomas


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

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


Mark


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

Hi Team,

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


*OS: Window *

*JAVA: 1.8.421*

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

Error:

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

#

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


#

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


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


# Problematic frame:

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

*#*

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


#

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

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

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

# See problematic frame for where to report the bug.

Attached the full error file.

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


Regards

Man Mohan



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


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

Re: Tomcat 10.1 Http11NioProtocol with the OpenSSLImplementation does not sent close_notify in response to client's close_notify

2024-08-30 Thread Mark Thomas

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

Isaac,

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

What is the "Tomcat Native Client"?

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

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

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

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

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

I have been using the manager app, something like

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

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

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

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

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

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

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

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

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

This should be fixed for the next round of releases.

Mark

-chris

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

Isaac,

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

Hello Tomcat Users

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

What is the "Tomcat Native Client"?

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

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

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

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

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

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

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

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

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

So...

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

-chris

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

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

Re: Apache Tomcat Upgrade to address Curl and libcurl vulnerabilities

2024-08-30 Thread Mark Thomas


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

Apache Tomcat Security Team:

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


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

Mark




Critical:
CVE-2023-38545

High:
CVE-2024-7264

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

Low:
CVE-2023-38546

Thank you,

John P. Kenan
DevSecOps Engineer
US Environmental Protection Agency



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

Re: Understanding ResorceLink property inheritance

2024-08-29 Thread Mark Thomas

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

The resource definition in server.xml

...

OK. The global resource looks good.

...

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

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

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

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

Mark

I get the following error:

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

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

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

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

Understanding ResorceLink property inheritance

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

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

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

Yes, but only under specific circumstances.

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

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

Why is that happening?

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

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

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

And this is one that forgets all parent parameters:

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

Mark

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

Re: Suggestion: Maven repository for Tomcat native library

2024-08-29 Thread Mark Thomas


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

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


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

Mark


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


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

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

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


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

What say you?

-Harri



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



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

Re: mod_jk retry continuing existing stream?

2024-08-29 Thread Mark Thomas


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

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

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

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


What have you got set for recovery_options on those workers?

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

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


Mark

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

Re: Understanding ResorceLink property inheritance

2024-08-29 Thread Mark Thomas

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

Understanding ResorceLink property inheritance

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

Yes, but only under specific circumstances.

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

Why is that happening?

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

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

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

And this is one that forgets all parent parameters:

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

Mark

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

Re: Tomcat takes over 1 minute to stop

2024-08-29 Thread Mark Thomas

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

Quoc,

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

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

Tomcat Version Used Time Taken to stop

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

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

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

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

Questions:

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

No.

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

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

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

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

+1 to the thread dump suggestion.

Mark

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

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

2024-08-28 Thread Mark Thomas

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


Mark


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

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

Thanks,

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


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






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







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






This should be fixed in the next round of releases.



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



   - Chuck






Here are some stack-traces.







1.







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



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



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



| SQL Code: 0 | SQL State: null















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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



at 
java.util.concurrent.Executors$RunnableA

Re: How to resolve 403 forbidden error in Tomcat level

2024-08-28 Thread Mark Thomas


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

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

Hi Team,

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

  I am using tomcat 9.0.91.

Thank you
Jagadish



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

Re: Suggestion: Maven repository for Tomcat native library

2024-08-27 Thread Mark Thomas


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

Mark

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

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

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

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

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

What say you?

-Harri



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

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

2024-08-22 Thread Mark Thomas


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

Hi,

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

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

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

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

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

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

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

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


It isn't. From RFC 9110:

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

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

The -gzip should be inside the double quotes.


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


Sorry, no.

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


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


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


Mark

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

Re: j_security_check error

2024-08-16 Thread Mark Thomas


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

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

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

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

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


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



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


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

Look for "landingPage"

Mark

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

Re: Bypassing Ldap in tomcat .

2024-08-16 Thread Mark Thomas


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

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


Oracle what? Database?

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

If all else fails

grep -R oracle *

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


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


So reset the password.

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


Mark

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

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

2024-08-15 Thread Mark Thomas


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




web browser clocking issues




Can you clarify what you mean by this please.

Mark

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

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

2024-08-14 Thread Mark Thomas


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

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


It will be included in the September release round.

Mark




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

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

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

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


Thanks. That is very helpful.

git bisect has identified this commit:

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

as the cause of the change in behaviour.

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

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


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

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

Mark

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



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

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

2024-08-14 Thread Mark Thomas


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

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


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


Thanks. That is very helpful.

git bisect has identified this commit:

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

as the cause of the change in behaviour.

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

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


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


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


Mark

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

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

2024-08-13 Thread Mark Thomas


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

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

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


Thanks. That is very helpful.

git bisect has identified this commit:

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

as the cause of the change in behaviour.

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

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

Mark

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

[ANN] Apache Tomcat Connectors 1.2.50 released

2024-08-13 Thread Mark Thomas


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


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

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

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

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

Thank you,
--
The Apache Tomcat Team

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

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

2024-08-11 Thread Mark Thomas


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

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


What makes multiple chunks correct and one chunk incorrect?

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



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


Really? What changes?


• Spring Version: 3.3.2.


Do you mean Spring Boot here?


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


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


Mark

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

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

2024-08-09 Thread Mark Thomas


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

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


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


Mark





--
Thanks and Regards,
Tushar Patil

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

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

Chuck,

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



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

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

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



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

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

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



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


+1

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

-chris

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




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

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

2024-08-08 Thread Mark Thomas


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



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

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

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



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

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

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



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


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

Mark

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

Re: Reg: tomcat CPU spikes

2024-08-08 Thread Mark Thomas


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

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




That won't work.

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





@Override

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


Mark

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

Re: Apache Tomcat Memory Allocation

2024-08-08 Thread Mark Thomas


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

Hi,

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


That is entirely expected.

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


*OS Details:*


This mailing lists drops images. Use plain text.

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


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

Mark

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

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

2024-08-08 Thread Mark Thomas





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

Hi Team,

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

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

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


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


Mark

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

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

2024-08-08 Thread Mark Thomas

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

Hi All,

Any suggestions or help on this ?

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

shall I create defect ?

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

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

Mark

Thanks

Channa

*From:* Channa Puchakayala >

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

Hi Tomcat Team,

Thanks to all for helping on this.

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

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

*@Chris,*

Please find the requested data below.

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

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

*Note:*

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

Regards

Channa

-Original Message-
From: Christopher Schultz >

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

Channa,

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

 > Hi Tomcat Team,

 >

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

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

 >

 > Observations:

 >

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

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

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

 >

 > -Tomcat log message is below

 >

 > =

 >

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

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

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

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

 >

 > 

 >

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

 >

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

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

 >

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

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

 >

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

 >

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

 > restart time

 >

 > Environment

 >

 > Red Hat Linux 8.6

 >

 > Java: OpenJDK 11.0.23 and 17.0.10

 >

 > Tomcat :  9.0.87 and 9.0.91

 >

 > Verified tomcat release notes and also tomcat defects in

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

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

 >

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

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

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

Can you post the results of these commands?

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

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

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

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

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

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

-chris

-

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

2024-08-06 Thread Mark Thomas


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

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

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M24 is a milestone release of the 11.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 11.0.x so that they may provide feedback. The notable
changes compared to 11.0.0-M22 include:

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

- Add FFM compatibility methods for LibreSSL and BoringSSL support.

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

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

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

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

Enjoy!

- The Apache Tomcat team

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

Re: AW: Problem getting logging from TldScanner

2024-08-06 Thread Mark Thomas


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

Hi Mark,
ah! Thanks! After I enabled

java.util.logging.ConsoleHandler.level = ALL

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


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


Thanks for bringing this to our attention.

Mark



Thanks,
   Andreas

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


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

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

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

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

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

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





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


You need:

... = FINEST

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

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

Mark

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



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

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



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

Re: Problem getting logging from TldScanner

2024-08-06 Thread Mark Thomas


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

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

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

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

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





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


You need:

... = FINEST

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


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


Mark

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

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

2024-08-01 Thread Mark Thomas


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

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



The error I get is

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



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


In the server.xml file I have


 
 



do you have any suggestions as to the issue?


Something other than Tomcat is listening on port 8081 using ipv6.
Use "netstat -tnalp" to identify it.

If you want to limit AJP to ipv4, use address "127.0.0.1" rather than 
"localhost". That might work depending on your OS.


Mark

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

Re: Jakarta EE 11 Release Delayed

2024-07-30 Thread Mark Thomas


On 30/07/2024 15:53, William Crowell wrote:

Good morning,

I received an update from the Jakarta EE Community mailing list this morning 
that the Jakarta EE 11 final release will be pushed out a quarter to deal with 
platform TCK migration to Arquillian/Junit 5. The exact target date is still 
TBD.

I am assuming this also pushes Apache Tomcat 11’s final release as well?


I don't see any reason for it to do that.

Tomact 11 milestones are already at beta meaning:

- the specifications Tomcat 11 implements have been released

- Tomcat fully implmements the specifications (and passes the Servlet,
  Pages, EL, WebSocket and Annotations TCKs)

My plan was to see how the August release went and - if things went well 
- start a discussion on the dev@ list about moving to stable releases 
for Tomcat 11.


In case by final release you meant EOL date, that will be driven by the 
release date for Tomcat 14 since we support 3 major releases in 
parallel. It is hard to predict that far in the future but past major 
Tomact releases have typically been support for ~10 years. At this point 
I dont see any reason why Tomcat 11 woudl be different.


Mark

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

Re: Reg: tomcat CPU spikes

2024-07-29 Thread Mark Thomas


On 26/07/2024 22:19, Jalaj Asher wrote:

Thanks Christopher.
But can we also consider allowing caching of different types as caching jar 
files is very valuable as that avoids jar scans real time when the production 
is under load .

But trying to cache static content, which can be cached separately on client 
end, or jsps which are compiled and cached in work folder don’t need to be 
loaded in memory as they force a significant increase in memory utilization.


Sounds like you need to provide a custom 
org.apache.catalina.WebResourceRoot$CacheStrategy implementation.


See https://tomcat.apache.org/tomcat-11.0-doc/config/resources.html 
towards the end of the page and 
https://tomcat.apache.org/tomcat-11.0-doc/api/org/apache/catalina/WebResourceRoot.CacheStrategy.html


Mark




Regards

Jalaj P Asher

-Original Message-
From: Christopher Schultz 
Sent: Monday, July 22, 2024 12:35 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/19/24 14:28, Jalaj Asher wrote:

This is the warning message we get when cachingAllowed is not set to
false

org.apache.catalina.webresources.Cache.getResource Unable to add the resource 
at [/WEB-INF/classes/] to the cache for web application [/x] because there 
was insufficient free space available after evicting expired cache entries - 
consider increasing the maximum size of the cache.


Okay, I see it. Specifically, it is a WARN message which is usually not 
suppressed in a production configuration.

@markt @remm what do you think about making this another of those "WARN the first 
time, DEBUG thereafter" kinds of messages?

It seems like if a cache is full, the operator SHOULD get a notification, but 
if the cache is thrashing, printing an error a huge number of times doesn't 
seem like it's terribly helpful. It just fills the disk.

-chris


-Original Message-
From: Jalaj Asher
Sent: Tuesday, July 16, 2024 1:30 PM
To: Tomcat Users List 
Subject: RE: Reg: tomcat CPU spikes


space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.

1. Also interesting. Can you post one of those messages here? Was there a stack 
trace shown or just the warning?

  It is just the warning. No stack trace. I will work on recreating this 
since all our environments has this disabled.

2. Interesting. How much static content do you have? This seems like a good 
use-case for a reverse-proxy to handle your staticcontent for you.
We have not collated the complete size of it. But are reasons we cannot do that.

Also I was reviewing some older heap dumps and I could see that the jars are 
getting cached in tomcat even with cachingAllowed=false.

Also this is not a consistent issue once it happens it takes sometime for the 
stack to go away as well as post tomcat reboots the problem goes away with the 
same settings and we do see that the wars are getting deployed during tomcat 
startup as well.

Regards

Jalaj P Asher


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 16, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.

Interesting. How much static content do you have? This seems like a good 
use-case for a reverse-proxy to handle your static content for you.


2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.

Also interesting. Can you post one of those messages here? Was there a stack 
trace shown or just the warning?

-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside of 
eClinicalWorks. Always use caution when opening attachments, clicking links, or 
when responding to this email. If you feel this is a phishing scam, please use 
the Phish Alert Report button in Outlook.


Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleas

Re: Seeking clarification on ServletContext.createServlet() behavior post context initialization

2024-07-25 Thread Mark Thomas


Ryan,

I think you are in territory that is undefined by the Servlet 
specification and is likely to remain that way.


The expectation is that ServletContext.createServlet() is used followed 
by addServlet(String, Servlet) and addServlet(String, Servlet) can only 
be used before content initialisation is complete.


Further, the @ServletSecurity annotations apply when a request is mapped 
to the Servlet by the container - not when the Servlet methods are 
called directly.


From the general description of the functionality your tool is 
providing, I would expect it to be implemented as a Filter.


Mark


On 24/07/2024 23:13, Ryan Lubke wrote:

Hey Folks,

Tomcat version: 10.1.26
JDK:   "21.0.3" 2024-04-16 LTS
OS: Macos Sonoma 14.5

I'm looking for clarification on what annotations will be supported when
calling ServletContext.createServlet() after the context has been
initialized.

Some background; I have a tool that inspects a web application where for
each discovered Servlet (either declared in the {web,web-fragment}.xml or
via annotations) will wrap that Servlet which performs additional logic
during init and service before calling through to the actual delegate that
we wrapped.  When this wrapper's init() is first called by the container,
we will instantiate the delegate using ServletContext.createServlet().  The
Servlet 6.0 specification states the following:

-
4.4.1.5.  T createServlet(Class clazz)

This method instantiates the given Servlet class. The method must support
all the annotations applicable to servlets except @WebServlet. The returned
Servlet instance may be further customized before it is registered with the
ServletContext via a call to addServlet(String, Servlet) as defined above.
The given Servlet class must define a zero argument constructor, which is
used to instantiate it.
-

This works fine for cases such as @Inject or @Resource, however, I've found
the behavior in the case of @ServletSecurity to differ between containers.
For example, Tomcat, Jetty, and Wildlfy appear to ignore @ServletSecurity
when calling createServlet() from the wrappers init() method.

However, section 13.4.1 has the following constraint on @ServletSecurity:
-
When metadata-complete=true is defined for a portable deployment
descriptor, the @ServletSecurity annotation does not apply to any of the
url-patterns mapped to (any servlet mapped to) the annotated class in the
deployment descriptor.
-

In my test case, the descriptor containing the original Servlet has the
metadata-complete attribute set to true.  If I set it to false, I find that
the security constraints are applied, but only when running with Jetty;
Tomcat and Wildfly continue to ignore the desired constraints.

Going back to section 4.4 for a moment which states:
-
The following methods are provided on the ServletContext interface to
enable programmatic definition of servlets, filters and the url pattern(s)
that they map to. These methods can only be called during the
initialization of the application either from the contexInitialized method
of a ServletContextListener implementation or from the onStartup method of
a ServletContainerInitializer implementation.
--

The javadocs for ServletContext.createServlet() don't impose any
restrictions on when it may be called unlike the javadocs for the various
dynamic registration methods.

I'm curious to see what the devs lurking here think.  What should the
behavior be?  It seems like the spec could use some tightening here either
way.

Thanks for your time.



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

[ANN] Apache Tomcat Native 2.0.8 released

2024-07-24 Thread Mark Thomas


The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 2.0.8 stable.

The key features of this release are:

- Fix a crash on Windows when SSLContext.setCACertificate() is invoked
  with a null value for caCertificateFile and a non-null value for
  caCertificatePath
- The windows binaries in this release have been built with OpenSSL
  3.0.14

The 2.0.x branch is primarily intended for use with Tomcat 10.1.x or 
later but can be used with earlier versions as long as the APR/native 
connector is not used.


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

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

The Apache Tomcat Native Library 2.0.x provides an API for using OpenSSL 
for SSL networking with Apache Tomcat.


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

Re: Reg: tomcat CPU spikes

2024-07-23 Thread Mark Thomas


On 22/07/2024 17:35, Christopher Schultz wrote:

Jalaj,

On 7/19/24 14:28, Jalaj Asher wrote:
This is the warning message we get when cachingAllowed is not set to 
false


org.apache.catalina.webresources.Cache.getResource Unable to add the 
resource at [/WEB-INF/classes/] to the cache for web application 
[/x] because there was insufficient free space available after 
evicting expired cache entries - consider increasing the maximum size 
of the cache.


Okay, I see it. Specifically, it is a WARN message which is usually not 
suppressed in a production configuration.


@markt @remm what do you think about making this another of those "WARN 
the first time, DEBUG thereafter" kinds of messages?


It seems like if a cache is full, the operator SHOULD get a 
notification, but if the cache is thrashing, printing an error a huge 
number of times doesn't seem like it's terribly helpful. It just fills 
the disk.


I'm not sure. If this happens occasionally, then an occasional message 
seems reasonable. If the cache is thrashing then that is bad and a slew 
of log messages highlighting that doesn't seem unreasonable.


Is there a valid case where you would want the cache to thrash?

Mark




-chris


-Original Message-
From: Jalaj Asher
Sent: Tuesday, July 16, 2024 1:30 PM
To: Tomcat Users List 
Subject: RE: Reg: tomcat CPU spikes


space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
1. Also interesting. Can you post one of those messages here? Was 
there a stack trace shown or just the warning?


 It is just the warning. No stack trace. I will work on recreating 
this since all our environments has this disabled.


2. Interesting. How much static content do you have? This seems like a 
good use-case for a reverse-proxy to handle your static    content for 
you.
We have not collated the complete size of it. But are reasons we 
cannot do that.


Also I was reviewing some older heap dumps and I could see that the 
jars are getting cached in tomcat even with cachingAllowed=false.


Also this is not a consistent issue once it happens it takes sometime 
for the stack to go away as well as post tomcat reboots the problem 
goes away with the same settings and we do see that the wars are 
getting deployed during tomcat startup as well.


Regards

Jalaj P Asher


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, July 16, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source outside 
of eClinicalWorks. Always use caution when opening attachments, 
clicking links, or when responding to this email. If you feel this is 
a phishing scam, please use the Phish Alert Report button in Outlook.



Jalaj,

On 7/15/24 18:18, Jalaj Asher wrote:

We ran into 2 issues
1. We needed to allocate significant amount of -XMX  for heap space,
if we allowed caching, since increasing memory by a few hundred MB as
well was not enough.
Interesting. How much static content do you have? This seems like a 
good use-case for a reverse-proxy to handle your static content for you.



2. Also with the setting being  enabled, it generated logs stating
"could not add a resource  as there wasn’t enough
space". Which was very quickly filling up our disk space as well as
increasing disk IO causing latency concerns.
Also interesting. Can you post one of those messages here? Was there a 
stack trace shown or just the warning?


-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, July 15, 2024 4:19 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an External Source 
outside of eClinicalWorks. Always use caution when opening 
attachments, clicking links, or when responding to this email. If you 
feel this is a phishing scam, please use the Phish Alert Report 
button in Outlook.



Jalaj,

On 7/15/24 15:03, Jalaj Asher wrote:

Yeah I was wondering the same as this has been in place since a few
years now atleast 4 years since cachingAllowed had some changes in
tomcat 8 which was resulting in it caching all static content as well
as jsps and jars and our though process was if we have static content
being cached on the client end and jsps in the work folder each time
on access we don’t need the cache.

Does the cache actively hurt you?

Is there a way to cache just the jars and not every thing else in 
memory ?


I think the short answer is "no there is not a way to do this" but I 
may be wrong.


The long answer might be "maybe, but you will have to play games with 
 and  and maybe some other things to get 
it working.


I would save yourself some complexity and simply enable caching.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, July 12, 2024 4:02 PM
To: users@tomcat.apache.org
Subject: Re: Reg: tomcat CPU spikes

Attention! - This email has originated from an Externa

Re: NoClassDef error

2024-07-22 Thread Mark Thomas


On 22/07/2024 15:31, Mcalexander, Jon J. wrote:

Hello,
I have an application team that is receiving the following exception after 
upgrading to Tomcat 9.0.90.

Exception java.lang.NoClassDefFoundError: 
org/apache/tomcat/dbcp/pool2/BasePooledObjectFactory

If they revert back to 9.0.89 it once again works. Was there a change to this 
component between 89 and 90?


Unused code was removed. That was one of the classes that was removed.

Applications should not be using Tomcat's internal fork of Commons Pool. 
They should add the Commons Pool JAR to WEB-INF/lib and use it directly.


Mark



Thank you,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.




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

Re: Tomcat http header size too large!

2024-07-15 Thread Mark Thomas


On 14/07/2024 00:28, Pradeep wrote:

Hi,

I need some tips to solve below issue.
I am getting 431 http error in API (code running in tomcat) when header
size crosses 8KB. Tomcat server doesn't process request if header size is
more than 8KB.
I tried adding below properties to increase the header size in Springboot
application.yaml:

server:
   tomcat:
   max-http-header-size: 16KB

Above solution didn't work, please advice if any other way can achieve
increasing header size.


You might be better off seeking help from the Spring community. That 
looks like the right property to set to me but there may well be some 
detail I am missing.


Another thing to check is how big your headers are. Are you sure 16KB is 
enough?


Mark

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

Re: Inquiry about CVE-2024-5535 Vulnerability in Tomcat 10.1.20 Version

2024-07-06 Thread Mark Thomas


On 06/07/2024 05:08, Zhong, Peyton wrote:

Dear Tomcat Community,

I am writing to inquire about the potential impact of the recently detected critical 
vulnerability: CVE-2024-5535 
(9.1 CRITICAL / CVSS v3), in OpenSSL 3.0.13 on the Tomcat 10.1.20 version. According 
to Black Duck Binary Analysis (BDBA) scans, this vulnerability has been identified 
within the Tomcat 10.1.20 version. There are other detected vulnerabilities inside 
OpenSSL on Tomcat, such as CVE-2024-4603
The detected file is: apache-tomcat-10.1.20/bin/tcnative-2.dll

Given this disconcerting discovery, we are seeking clarification on how 
CVE-2024-5535 may affect the Tomcat 10.1.20 version. It is of utmost importance 
for us to understand the implications of this vulnerability and to identify any 
available mitigations or patches to address this issue.

Your prompt attention to this matter is highly valued, and we would be grateful 
for any assistance or guidance you can provide to help us navigate this 
potential security concern.

Thank you for your time and consideration.


Another illustration of why CVSS scores are a bad idea.

Did you read the description from the OpenSSL project for CVE-2024-5535? 
Its severity is low, not critical. If you did read the descrition, did 
you check the Tomcat Native source code to see if Tomcat uses the method 
in question?


Same questions for CVE-2024-4603.

For CVE-2024-4603 did you read the description from the OpenSSL project? 
Are you using an affected configuration? If yes, can you switch to one 
that isn't affected?


You have access to all the information you need to be able to answer 
your questions yourself. If it is important to you as you say it is then 
why are you asking us to do the work for you rather than doing it yourself?


There are no plans at present for a new Tomcat Native release to pick up 
an updated OpenSSL version for the Windows binaries. However, given that 
some valid/likely configurations are affected, it is probable that there 
will be a Tomcat Native release some time this month so it can be picked 
up for the August Tomcat releases.


Mark

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

[ANN] New committer: Dimitris Soumis

2024-07-05 Thread Mark Thomas


On behalf of the Tomcat committers I am delighted to announce that
Dimitris Soumis (dsoumis) has been voted in as a new Tomcat committer.

Please join me in congratulating Dimitris.

Kind regards,

Mark

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

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

2024-07-05 Thread Mark Thomas


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

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

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M22 is a milestone release of the 11.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 11.0.x so that they may provide feedback. The notable
changes compared to 11.0.0-M21 include:

- Move OpenSSL support using FFM to a separate JAR named
  tomcat-coyote-ffm.jar that advertises Java 22 in its manifest.

- When using include directives in a tag file packaged in a JAR file,
  ensure that the include directives are processed correctly.

-  Expand the implementation of the filter value of the Authenticator
   attribute allowCorsPreflight, so that it applies to all requests that
   match the configured URL patterns for the CORS filter, rather than
   only applying if the CORS filter is mapped to /*

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

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

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

Enjoy!

- The Apache Tomcat team

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

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

2024-07-03 Thread Mark Thomas


CVE-2024-34750 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

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

Description:
When processing an HTTP/2 stream, Tomcat did not handle some cases of 
excessive HTTP headers correctly. This led to a miscounting of active 
HTTP/2 streams which in turn led to the use of an incorrect infinite 
timeout which allowed connections to remain open which should have been 
closed.


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

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by devme4f from VNPT-VCI.


History:
2024-07-03 Original advisory

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

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

[ANN] New committer: Chuck Caldarale

2024-07-03 Thread Mark Thomas


On behalf of the Tomcat committers I am delighted to announce that
Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.

Please join me in congratulating Chuck.

Kind regards,

Mark

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

Re: How to configure Tomcat with a Managed Service Account when using LocalMachine certificates for TLS

2024-06-25 Thread Mark Thomas


On 25/06/2024 14:27, Gavioto 🕵 wrote:

- how are are starting Tomcat?
  Tomcat is starting as a service with "Domain\account1$" (Managed Service 
Account)

- is Tomcat installed as a Windows service?
  Yes

- which account is Tomcat running under?
  "Domain\account1$" (Managed Service Account)


OK. That clarifies things. Thanks.




My actual configuration

Server version name:   Apache Tomcat/9.0.65
Server version number: 9.0.65.0
Server built:  Jul 14 2022 12:28:53 UTC


Getting on for two years old. There are known security vulnerabilities 
in that version. You definitely want to make sure they don't impact your 
environment and you may want to think about upgrading.






Attribute names are case-sensitive. You have serveral starting with an 
upper case 'K' when they should all be lower case.


I'd expect you to see some warnings in the logs on startup about 
unrecognised attributes.


Mark

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

Re: How to configure Tomcat with a Managed Service Account when using LocalMachine certificates for TLS

2024-06-25 Thread Mark Thomas


A few questions:

- how are are starting Tomcat?

- is Tomcat installed as a Windows service?

- which account is Tomcat running under?

There are a few references to "user" in your question. It is not clear 
if this is:

- the user administering a Tomcat service
- a user that is starting Tomcat from the command line
- the user that the Tomcat service is running as
- something else

Mark


On 25/06/2024 11:30, Alberto Corral wrote:

Hello!

After some research, docs, and test, I didn't found an answer to my issue.

I'm writing to the list  because I have to configure a probably not very common 
Tomcat configuration and didn't found correct configuration of if it is posible 
to do it.
Also I didn't find previous information or examples on internet and the wiki.

There is a similar question in Server Fault 
https://serverfault.com/questions/1161457/can-i-use-certificates-in-the-local-machine-from-a-managed-service-account,
 but not solved yet.

The configuration has been also involved with a JDK recent bug-fix (but 10 
years old), but this part is fixed using latest available JDK versions.
So I think it would be valuable to document an Use Case based on real 
experience that can be both, tested in future versions, and also useful for 
future users, available in the wiki or official docs :-)

May be what's I'm trying to do is not really possible, but need to know if this 
is a Tomcat limitation or a Windows one.

My actual configuration

Server version name:   Apache Tomcat/9.0.65
Server version number: 9.0.65.0
Server built:  Jul 14 2022 12:28:53 UTC
Architecture:  amd64
OS Version:10.0
OS Name:   Windows Server 2019
JVM Vendor:Eclipse Adoptium
JVM Version:   11.0.23+9
Java Home: 
C:\OpenJDK11U-jdk_x64_windows_hotspot_11.0.23_9\jdk-11.0.23+9

Actual secure configuration used:




Configuration:
- The certificate is in the LOCALMACHINE Windows Storage and allows read access to the 
user "account1$" which is an AD Managed Service Account.
-

Facts:
- If the user have read access but not local admin, then the previous stack 
trace is generated.
- If I give local Admin rights to the service account, it seems can access to 
the Certificate Storage, in other case, the previous Stack Trace is generated.
- Unless I gave local Admin rights, apache opens port 8443, but doesn't respond 
to requests on 8443 when testing and no error in logs appears.

What is the question is "How to configure Tomcat with a Managed Service Account when 
using LocalMachine certificates for TLS"

Notes:
- JDK 11.0.20+ is required due a well known bug that has been backported from JDK 21  
[JDK-6782021] It is not possible to read local computer certificates with the SunMSCAPI 
provider - Java Bug System (openjdk.org) 
(https://bugs.openjdk.org/browse/JDK-6782021) and [JDK-8303520] It is not possible to read 
local computer certificates with the SunMSCAPI provider - Java Bug System 
(openjdk.org) (https://bugs.openjdk.org/browse/JDK-8303520)

Next program can help to check different configurations, and it works when the 
certificate has read permission for the user who is running it.

// JDK8313367test.java - Simple test case to demonstrate OpenJDK defect 
JDK-8313367
// References:
// * https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8313367
// * 
https://stackoverflow.com/questions/75255985/java-keystore-type-windows-my-root-localmachine-requires-administrator-permissio

/*
Here is the command line to run the test using JDK 11.0.20+,  17.0.20+ or 
20.0.2+
java --add-modules=jdk.crypto.mscapi 
--add-exports=jdk.crypto.mscapi/sun.security.mscapi=ALL-UNNAMED 
JDK8313367test.java
*/

import java.io.*;
import java.security.KeyStore;
import java.security.Security;
import java.util.Enumeration;
import sun.security.mscapi.SunMSCAPI;

public class JDK8313367test {
 public static void main(String[] args) {
 try {
 Security.addProvider(new SunMSCAPI());
 KeyStore keyStore = 
KeyStore.getInstance("Windows-My-LOCALMACHINE");
 // When running as non-elevated, the SunMSCAPI provider, enhanced 
with JDK-6782021, incorrectly
   // triggers system error 5 "Access is denied" when 
attempting to load the keystore when invoking the following method:
   keyStore.load(null, null);
 Enumeration aliases = keyStore.aliases();
   // Print Friendly Names, a.k.a. aliases, of each certificate 
in the keystore
 for (int i = 0 ; aliases.hasMoreElements() ; i++) {
 System.out.println( aliases.nextElement() );
 }
 } catch (Exception e) {
 throw new RuntimeException(e);
 }
 }
}

Pending tests:
- What I haven't tested, but it is an idea to test, is to launch this code from 
Tomcat and validate if it works (It isn't possible to run a CLI program using a 
Managed Service Acc

Re: Errors after upgrading to Tomcat 9.0.90

2024-06-20 Thread Mark Thomas

That looks like an issue accessing a request/response after the 
request/response has been completed.


Possibly surfaced by this entry from the change log:

The system property org.apache.catalina.connector.RECYCLE_FACADES will 
now default to true if not specified, which will in turn set the default 
value for the discardFacades connector attribute, thus causing facade 
objects to be discarded by default. (remm)


You could try explicitly setting discardFacades to false.

Mark


On 20/06/2024 11:25, Francesco Chicchiriccò wrote:

Hi there,
at Syncope we usually use the latest Tomcat versions to run a large 
chunk of our integration tests.


In our master branch we relay on Tomcat 10.1.x, and upgrading to 10.1.25 
from 10.1.24 went smooth as usual.


In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89 everything 
goes as expected, but with 9.0.90 we are getting the exception [1].


Any idea of what could be changed in 9.0.90 within this regard? Thank you.

Regards.


[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34



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

Re: Configuration of Certificate Verification on Tomcat 10

2024-06-19 Thread Mark Thomas

On 18/06/2024 23:30, Christopher Schultz wrote:

Izek,

On 6/18/24 13:49, Izek Hornbeck wrote:

I am creating a Java web app (Java v17, 2021-09-14) that runs on a Tomcat
10.1.23 server. I need to authenticate users by verifying their
certificate

from a smart card. (This Stack Overflow question I posted gives some good
context: "
https://stackoverflow.com/questions/78387597/what-is-the-standard-modern-way-to-use-cac-piv-card-authentication-in-java-tomca
".)

Through all the research I have done, the best way to solve this is by
using the server configuration in "server.xml". I am very new to Tomcat,
but I will try to explain everything as best as I can.

This authentication must occur after the user has entered their
credentials, so I'm thinking the best way is to redirect the user to a
new

port (e.g., from 8443 to 8444) with the appropriate settings. And some
users will not be required to authenticate with a smart card
certificate. I

asked another question on Stack Overflow ("
https://stackoverflow.com/questions/78624062/how-to-get-the-popup-menu-to-select-user-certificate-in-tomcat-10-server";)
that describes more of the things that I have tried specific to the
server

config.

I added the command "-Djavax.net.debug=ssl" to see more details about
what

was happening during the SSL handshake; I get the following:
- javax.net.ssl|ALL|F3|https-jsse-nio-8444-exec-6|2024-06-18
10:25:02.564

According to some sources (like "
https://stackoverflow.com/a/11803823/1587";) this happens because some
certificates have not yet been added to the keystore/truststore. I have
ensured that the test client certificates and the server certificate have
been successfully added to the stores.

The two major questions I have are these:
1) How can I get the popup menu for the user to select their
certificate
and enter the smart cards pin? (Both to set up their account and for
later

logins.)
2) How do I configure my server to accept the clients' certificates?

Let me know what more information would be useful.

Starting from your SO post:

> protocol="org.apache.coyote.http11.Http11NioProtocol"
> port="8444" maxThreads="150" SSLEnabled="true"
> maxParameterCount="1000" secure="true" scheme="https" >
>
> sslProtocol="TLSv1.2"
> certificateVerification="true"

You don't actually want certificateVerification="true" here, unless you
want every single connection to require a certificate to be presented.
Since you mentioned you need to be able to support "sign up" and also
first request some other kind of authentication (username/password?) and
also some resources without client-certs, this setting *must* be set to
something else.

I suspect you want clientAuth="false" which is counterintuitive, but it
means that the web application gets to set the policy for if/when client
certs are requested.

That means that your WEB-INF/web.xml file needs to declare one or more
web-resource-collection elements as requiring CLIENT-CERT authentication.

I *think* that if you have clientAuth="false" you will get the behavior
you want, but you are going to have to set up some places in your
application where client certs are required versus not-required. Since
you are building a new application and not trying to retrofit an old
one, this may be relatively easy. Here's my recommendation:

This won't work. You can only have 1 authentication mechanism per web
application. You might need to split functionality between multiple web
applications.

Mark

1. Unauthenticated web-resource-collection

This basically has your login informational resources that never require
any authentication in order to view. That includes images, CSS, etc. No
need to define any authentication constraints.

2. Semi-authenticated web-resource-collection

This is only accessible to users who have successfully logged-in using
your "easy" criteria such as username+password. Probably also any pages
you need to display that say "okay, now you need to register your client
certificate with your account" or whatever.

For this, you must set the user-roles you will allow to view these
resources. You can use any combination of roles (I recommend "*"),
because unauthenticated users have no roles. You can probably use "FORM"
as the authentication type if you are using e.g. username+password.

3. Fully-protected web-resource-collection

These resources are only accessible using a client certificate. After
registration, or after you have determined that a user must use

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

2024-06-18 Thread Mark Thomas


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

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

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M21 is a milestone release of the 11.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 11.0.x so that they may provide feedback. The notable
changes compared to 11.0.0-M20 include:

- Ensure that static resources deployed via a JAR file remain accessible
  when the context is configured to use a bloom filter. Based on a pull
  request provided by bergander.

- Add task queue size configuration on the Connector element, similar to
  the Executor element, for consistency.

- Update to Commons Daemon 1.4.0

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

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

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

Enjoy!

- The Apache Tomcat team

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

Re: A curious case of Tomcat 10.1.x NIO(1) acceptor not stopping clearly on some setups

2024-06-14 Thread Mark Thomas

Just to follow up on this.

I tripped over a related issue today running the Tomcat unit tests for
9.0.x. Being able to reproduce it gave me a chance to dig further and
come up with a better fix. These interfaces are marked as "point to
point" interfaces which Java can see so we can skip them. I've updated
the unlock code and the fix will be in the July release round.

Mark

On 26/02/2024 15:59, Michał Szymborski wrote:
Thank you, that clears things up. I did not think about implication of
using wildcard. I will try to use explicit addresses from now on. You
learn something new every day!

Cheers,
Michał

On 26.02.2024 09:48, Mark Thomas wrote:

On 25/02/2024 18:18, Michał Szymborski wrote:

On quick inspection the acceptor thread
(https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/Acceptor.java#L128) was listening on [/[0:0:0:0:0:0:0:0]:39033]
, which was correctly picked up at first, but then this local address
got transformed:

0.0.0.0 is shorthand for "all configured IP address". Tomcat can't use
that address to establish a connection to the Acceptor thread so it
has to try and deduce a valid IP local address from the network
configuration information exposed through the Java APIs.

https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1164

It started picking up interfaces to use, and it stopped at the first
non-loopback non-link local address, which also happens to be some
sort of a bridge network for one of my VMs. I don't quite know why
there is no routing set up, but this interface should not have been
picked in the first place.

It is a local IP address so as far as Tomcat can see it should be
valid to connect to the Acceptor.

I'll take a look at how it works on my work laptop with MacOs, but
I'd wager a guess that some corporate VPNs have interfaces which have
messed up routing as well. Can't tell if it's a bug or a feature, but
it sure is unexpected. Making this timeout for acceptor shutdown
configurable would be one sort of band-aid.

It is configurable. socket.unlockTimeout. Documented default is 250ms
although looking at the code it appears there is a minimum of 2000ms -
need to see why that is.

Configuring a specific address (even 127.0.0.1) for the Connector
would also address this.

Mark

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

Re: EOL of servelet-api

2024-06-12 Thread Mark Thomas


On 12/06/2024 10:54, Madhu Mitha (EXT-Nokia) wrote:

Hi,

I'm currently using Apache Tomcat 9.0.86, in my component(JOMA) that runs in 
RHEL 8.6.
Customer has triggered security scan and found servlet-api.jar has reached EOL 
in 2018 and the recommendation is to migrate to Jakarta-servelet-api.jar.


You need to get a better security scanner. That statement is nonsense 
for Tomcat 9. The servlet-api.jar provided with Tomcat 9.0.x is 
currently supported and will continue to be supported for as long as 
Tomcat 9.0.x is supported.



So, when can we expect the changes from Tomcat. Unless or until you change 
this, I cannot deploy in my component.


If you had bothered to do even a minimal amount of research you would 
know that Tomcat 10.x is already available (and has been for over 3.5 
years) with Jakarta EE support.



Please reply with the timeline on the availability of this, or any alternate 
way to mitigate this.


See above.

Mark

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

Re: Mysterious websocket disconnection--no logs

2024-06-11 Thread Mark Thomas


On 09/06/2024 01:08, Flaviu Tamas wrote:

I'm writing some tests for my Spring Boot application, which uses
tomcat-embed-websocket-10.1.18. When I send a message to the socket
from handleVideoFrame, all I see is

.WebSocketAnnotationMethodMessageHandler : Invoking
VideoStreamController#handleVideoFrame[3 args]
o.s.w.s.m.SubProtocolWebSocketHandler: Clearing session
3b7fc290-eeb3-a86c-a465-8826819f3bde

I can turn debug logging on for org.apache.tomcat.websocket.WsSession,
which give me a bit more detail, but this is detail that the
application user is unlikely to care about (some sort of internal ID
that I don't think is exposed anywhere else)

.WebSocketAnnotationMethodMessageHandler : Invoking
VideoStreamController#handleVideoFrame[3 args]
org.apache.tomcat.websocket.WsSession: Closing WebSocket session [3]
o.s.w.s.m.SubProtocolWebSocketHandler: Clearing session
a77dcddd-877e-1d5a-8dd2-daf3f38395f7

This is especially frustrating because this log line has complete
context. If I place a breakpoint in WsSession.doClose, I can see that
the error is "The decoded text message was too big for the output
buffer and the endpoint does not support partial messages", which does
help me solve my problem.

It would be nice if this message was exposed to the user, either by
default, or at the very least in the debug logs.


The message is sent to the user/client as part of the WebSocket close 
message. If the client doesn't expose that to the user, there isn't much 
Tomcat can do.


Mark

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

Re: Side effect of Tomcat 10.1.20 with Freemarker

2024-06-11 Thread Mark Thomas


On 11/06/2024 12:30, Mark Thomas wrote:



I need to confirm that it doesn't break the original fix but my plan is 
to check clazz after line 2311 and rethrow the original exception if it 
is null.


Testing with the original reproducer looks good.

Fixed in:
- 11.0.x for 11.0.0-M21 onwards
- 10.1.x for 10.1.25 onwards
-  9.0.x for  9.0.90 onwards

Mark

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

Re: Side effect of Tomcat 10.1.20 with Freemarker

2024-06-11 Thread Mark Thomas


On 07/06/2024 09:04, Jeroen Hoffman wrote:


On 06-Jun-24 18:17, Mark Thomas wrote:

On 06/06/2024 11:01, Jeroen Hoffman wrote:

Hi all,

We've found a side effect of change #68721 [1] in Tomcat 10.1.20 that 
we'd like to notify you about.


We're using Apache Freemarker for back-end templating, and its 
NodeModel class uses reflection to determine what classes to use for 
xpath, thereby catching IllegalAccessError, see [2].


Per change #68721 a IllegalAccessError is caught as LinkageError and 
turned into a Throwable, NoClassDefFoundError in our case, see [3], 
and then falls through that block in NodeModel and errors out.


So this change in Tomcat alters the behaviour in Freemarker, which I 
assume was unexpected. We can (and must) work around it, preventing 
the IllegalAccessError, but still, maybe you'd like to improve again 
or have other thoughts?


How are you getting from the original IllegalAccessError to a 
NoClassDefFoundError? Tomcat should re-throw the original 
IllegalAccessError.


Small correction from my side: WebappClassLoaderBase throws a 
ClassNotFoundException (not NoClassDefFoundError) at the end of 
#loadClass (line 1353).


It's not re-throwing the original IllegalAccessError because the call to 
#findLoadedClass0(name) at line 2361 is NOT throwing anything, just 
returns null and then the ClassNotFoundException is thrown.


This specific case is about an anonymous inner class that implements 
PrefixResolver from the java.xml module, see 
https://github.com/apache/freemarker/blob/2.3/freemarker-core/src/main/java/freemarker/ext/dom/SunInternalXalanXPathSupport.java


Got it. Thanks for the explanation.

I need to confirm that it doesn't break the original fix but my plan is 
to check clazz after line 2311 and rethrow the original exception if it 
is null.


Mark

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

Re: Embedded Tomcat common classloader

2024-06-06 Thread Mark Thomas


On 06/06/2024 18:48, Dave Breeze wrote:

Thanks Mark
appreciate that the url was for 8.0

With regards to classpath that was my first attempt - unfortunately it
would seem that Tomcat does not support wildcards in the classpath -
for example dirpath/lib/*.jar - at least in version 9.


The requirements for setting the class path are set by the JVM, not by 
Tomcat. If you want all the JARs in a directory to be included in the 
class path then you should add dirpath/lib/* to the class path.


Mark





Dave Breeze
Linkedin:https://uk.linkedin.com/in/dabreeze

On Thu, 6 Jun 2024 at 17:23, Mark Thomas  wrote:


On 06/06/2024 17:52, Dave Breeze wrote:

   I have an issue with embedded Tomcat and classloaders.

I have a java servlet application that runs in an embedded
Tomcat(9.0.70) instance.





https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html


Those are the Tomcat 8.0.x docs. You are using Tomcat 9.0.x.

Tomcat embedded does not set up the class loader structure you get with
a standard Tomcat instance. Tomcat just uses the classpath.

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: Embedded Tomcat common classloader

2024-06-06 Thread Mark Thomas


On 06/06/2024 17:52, Dave Breeze wrote:

  I have an issue with embedded Tomcat and classloaders.

I have a java servlet application that runs in an embedded
Tomcat(9.0.70) instance.





https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html


Those are the Tomcat 8.0.x docs. You are using Tomcat 9.0.x.

Tomcat embedded does not set up the class loader structure you get with 
a standard Tomcat instance. Tomcat just uses the classpath.


Mark

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

Re: Side effect of Tomcat 10.1.20 with Freemarker

2024-06-06 Thread Mark Thomas


On 06/06/2024 11:01, Jeroen Hoffman wrote:

Hi all,

We've found a side effect of change #68721 [1] in Tomcat 10.1.20 that 
we'd like to notify you about.


We're using Apache Freemarker for back-end templating, and its NodeModel 
class uses reflection to determine what classes to use for xpath, 
thereby catching IllegalAccessError, see [2].


Per change #68721 a IllegalAccessError is caught as LinkageError and 
turned into a Throwable, NoClassDefFoundError in our case, see [3], and 
then falls through that block in NodeModel and errors out.


So this change in Tomcat alters the behaviour in Freemarker, which I 
assume was unexpected. We can (and must) work around it, preventing the 
IllegalAccessError, but still, maybe you'd like to improve again or have 
other thoughts?


How are you getting from the original IllegalAccessError to a 
NoClassDefFoundError? Tomcat should re-throw the original 
IllegalAccessError.


Mark

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

Re: Invalid character found in the request target

2024-06-05 Thread Mark Thomas


On 04/06/2024 15:37, Christopher Schultz wrote:

On 6/4/24 09:10, Chuck Caldarale wrote:





The problem is the { and } characters.

My reading of RFC 7230 is that { and } /should/ be allowed, but 
Tomcat's code rejects them by default.


My reading is as follows:

RFC 9110:

http-URI = "http" "://" authority path-abempty [ "?" query ]

RFC 3968:

path-abempty  = *( "/" segment )
segment   = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
  / "*" / "+" / "," / ";" / "="

Neither '{' nor '}' are included in unreserved or sub-delims The are not 
pct-encoded. Nor are they ':' or '@'. Therefore, there are not valid for 
use in a segment. If you want to use them, they need to be pct-encoded.


While some of the text of RFC 3968, section 2.3 could be read as 
suggesting other characters are included in unreserved, my reading of 
that section is that the intended definition of unreserved is the 
explicit definition I quoted above.


Mark

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

Re: Tomcat 9.0.xx JDK Version Support and EOL

2024-06-05 Thread Mark Thomas


On 05/06/2024 15:11, Chaitanya Gopisetti wrote:

Also can you update on the End of life expected date for Tomcat 9.0.x version


Best guess (based on the next major release being in ~3 years time) 
right now is 31 March 2027 for 9.0.x noting that a 9.10.x will follow to 
retain supoprt for the Java EE APIs.


We will provide at least 12 months notice of any offical EOL date for 9.0.x.

We expect to support 9.x for an extended period of time.

When 10.x reaches EOL so will 9.10.x and then we'll have 9.11.x and so on.

Mark



-Original Message-
From: Christopher Schultz 
Sent: Wednesday, June 5, 2024 6:37 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.xx JDK Version Support and EOL

Chaitanya,

On 6/5/24 08:47, Chaitanya Gopisetti wrote:

It was mentioned that Tomcat 9.0.x supports java 8 and later. So
wanted to know whether it supports Jdk 21? Also wanted to know the End
of life expected date for Tomcat 9.0.x version.


Tomcat 9 should run jut fine on any Java version from 8 up through the latest 
release (currently Java 21).

-chris

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


To the extent permitted by law, we may monitor electronic communications for 
the purposes of ensuring compliance with our legal and regulatory obligations 
and internal policies. We may also collect email traffic headers for analyzing 
patterns of network traffic and managing client relationships. For additional 
information see https://blueyonder.com/privacy-policy.

-
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: Webapp Getting redirected to an external IP Address

2024-06-03 Thread Mark Thomas


On 04/06/2024 05:07, Tom Robinson wrote:

Hi,

We are running a tomcat7 application


You do realise that support for Tomcat 7 ended on 31 March 2021 don't you?


on our LAN which gets redirected from
a private, internal IP Address to an external ip address at which point it
fails. I can't find where this is happening.


Is it an actual redirect - i.e. a 30x response? Or do you mean something 
else?


If a redirect, does it redirect on the first request?


Where and what can I check for this redirect and how to control it or
switch it off all together.


Tomcat doesn't do this by default.

Tomcat 7 doesn't have the redirect valve so it won't be that.

Are you sure that the redirect is being issued by Tomcat? Might there be 
a reverse proxy in mix somewhere?


Other than that, it would have to be in the application code somewhere.



I browse to here on our LAN:

https://myinternalhost.mydomain.com.au:8443


Check what myinternalhost.mydomain.com.au resolves to in terms of an IP 
address.


Try requesting a page that won't trigger a directory redirect. Something 
like:


https://myinternalhost.mydomain.com.au:8443/index.html

You may need to adjust that for your application.

Mark



I end up here:

https://a.b.c.d:8443/kb

Where a.b.c.d is our external, ISP provided IP Address.

Why is this happening and how can I fix it?

*Kind regards,*

*Tom Robinson*
*IT Manager/System Administrator*



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

Re: Cannot invoke "org.apache.tomcat.util.net.SSLHostConfig.getProtocols()" because "this.sslHostConfig" is null

2024-06-03 Thread Mark Thomas


On 03/06/2024 09:16, Adam Danischewski wrote:


Not sure why I'm getting:

Caused by: java.lang.NullPointerException: Cannot invoke
"org.apache.tomcat.util.net.SSLHostConfig.getProtocols()" because
"this.sslHostConfig" is null


You haven't configured a default SSLHostConfig.

Either use "_default_" for the host name of the SSLHostConfig you have 
defined or call setDefaultSSLHostConfigName("localhost") on the endpoint.


Mark

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

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

2024-05-31 Thread Mark Thomas


On 31/05/2024 16:09, Eric Robinson wrote:

The results are looking great so far.


Excellent.


Here's what we know:

Before the patch, we had 2 load-balanced tomcats in production for this 
customer. Due to the driver search bottleneck, we were seeing hundreds of stuck 
threads during the slowdown periods. To work around this problem, we threw more 
tomcats at it. With 6 tomcats, the load was spread around enough to keep the 
bottleneck condition from manifesting badly, and users did not complain as 
much. We were still seeing dozens of stuck threads, but not hundreds.

After the patch, we went back to 2 tomcats.


I appreciate the show of faith! I think that is braver than I would have 
been but it does rather confirm both the problem and the fix.



During the same timeframe today, there have been 1 stuck thread on Tomcat A and 
6 on Tomcat B.


That is great news.


If the numbers hold, this works out to roughly a 10,000% improvement.


Not bad for free support ;)

Seriously, I am glad that we seem to have tracked down the root cause 
and that you have a temporary fix that works until such time (probably 
the July releases) that we can figure out how we want to address caching 
of "not found" classes.


Cheers,

Mark

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

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

2024-05-30 Thread Mark Thomas


OK.

This is an interim binary patch for 9.0.80 only.

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

This is the binary patch:

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

Extract the contents into $CATALINA_HOME/lib

You should end up with:

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

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


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


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


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


Let us know how you get on and good luck.

Mark


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

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



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


Ack.

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


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


   


Mark

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



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

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

2024-05-30 Thread Mark Thomas


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




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


Ack.

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


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


  


Mark

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

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

2024-05-29 Thread Mark Thomas


On 29/05/2024 16:08, Eric Robinson wrote:


I believe your assessment is correct. How hard is it to enable pooling? Can it 
be bolted on, so to speak, through changes to the app context, such that the 
webapp itself does not necessarily need to implement special code?


It looks like - from the database configuration you provided earlier - 
there is an option to configure the database via JNDI. If you do that 
with Tomcat you will automatically get pooling. That might be something 
to follow up with the vendor. If you go that route, I'd recommend 
configuring the pool to remove abandoned connections to avoid any issues 
with connection leaks.


Not sure if all the web applications support a JNDI based configuration.




Would the problem be relieved if the vendor stuck to one driver?


Yes. That would avoid the attempt to load the "other" driver which is 
causing the delay.


Mark

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

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

2024-05-29 Thread Mark Thomas


On 29/05/2024 13:38, Eric Robinson wrote:

-Original Message-
From: Mark Thomas 





I intend to wok on a patch for Tomcat that will add caching that should
speed things up considerably. I hope to have something for Eric to test
today but it might take me until tomorrow as I have a few other time
critical things fighting to get tot he top of my TODO list at the moment.


Moving the JDBC driver JARs from WEB-INF/lib to $CATALINA_BASE/lib may
also be a short-term fix but is likely to create problems if the same
JAR ever exists in both locations at the same time.


Just an FYI. On further reflection, moving the JDBC driver JARs isn't 
going to help. Sorry. You'll need my fix.


Assuming, of course, you are willing to test a patch to address this on 
a production system.



That's some great sleuthing and the explanation makes a ton of sense. It leaves 
me with a couple of questions.

If you are correct, then it follows that historic activity has been hovering 
dangerously near the threshold where this symptom would manifest. Within the 
past month, an unknown change in the system climate now causes an uptick in the 
number of DB requests/second at roughly the same time daily (with occasional 
exceptions) and the system begins to trip over its own feet. I haven't seen 
anything in my Zabbix graphs that stood out as potentially problematic. Armed 
with this information, I am now taking a closer look.


Ack.


The natural next question is, what changed in the application or the users' 
workflow to push activity over the threshold? We'll dig into that.


Could be all sorts of things.

It might just have been coincidence the first time and now the users all 
request the data they need at the start of their day in case the problem 
happens again. And by doing that they cause the very problem they are 
trying to avoid.


Mark

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

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

2024-05-29 Thread Mark Thomas


On 29/05/2024 10:26, Mark Thomas wrote:

On 28/05/2024 16:26, Eric Robinson wrote:



Took a bunch of thread and heap dumps during today's painful debacle. 
Will send a link to those as soon as I can.


Thanks. I have them. I have taken a look and I am starting to form a 
theory. To help with that I have a couple of questions.


Scratch that. I've found some further information in the data Eric sent 
me off-list and I am now pretty sure what is going on.


There are multiple web applications deployed on the servers. I assume 
there are related but it actually doesn't matter.


At least one application is using the "new" MySQL JDBC driver:
com.mysql.cj.jdbc.Driver

At least one application is using the "old" MySQL JDBC driver:
com.mysql.jdbc.Driver


(I've told Eric off-list which application is using which).

There are, therefore, two drivers registered with the java.sql.DriverManager


The web applications are not using connection pooling. Or, if they are 
using it, they are using it very inefficiently. The result is that there 
is a high volume of calls to create new database connections.


This is problem number 1. Creating a database connection is expensive. 
That is why the concept of database connection pooling was created.



When a new connection is created, java.sql.DriverManager iterates over 
the list of registered drivers and

- tests to see if the current class loader can see the driver
- if yes, tests to see if that driver can service the connection url
- if yes, use it and exit
- go on to the next driver in the list and repeat

The test to see if the current class loader can use the driver is, 
essentially, to call Class.forName(driver.getClass(), true, classloader)


And that is problem number 2. That check is expensive if the current 
class loader can't load that driver.



It is also problem number 3. The reason it is expensive is that class 
loaders don't cache misses so if a web application has a large number of 
JARs, they all get scanned every time the DriverManager tries to create 
a new connection.



The slowness occurs in the web application that depends on the second 
JDBC driver in DriverManager's list. When a request that requires a 
database connection is received, there is a short delay while the web 
application tries, and fails, to load the first JDBC driver in the list. 
Class loading is synchronized on class name being loaded so if any other 
requests also need a database connection, they have to wait for this 
request to finish the search for the JDBC driver before they can 
continue. This creates a bottleneck. Requests are essentially rate 
limited to 1 request that requires a database connection per however 
long it takes to scan every JAR in the web application for a class that 
isn't there. If the average rate of requests exceeds this rate limit 
then a queue is going to build up and it won't subside until the average 
rate of requests falls below this rate limit.




Problem number 1 is an application issue. It should be using pooling. It 
seems unlikely that we'll see a solution from the application vendor and 
- even if the vendor does commit to a fix - I suspect it will take months.



Problem number 2 is a JRE issue. I think there are potentially more 
efficient ways to perform that check but that needs research as things 
like OSGI and JPMS make class loading more complicated.



Problem number 3 is a Tomcat issue. It should be relatively easy to 
start caching misses (i.e. this class loader cannot load this class) and 
save the time spent repeatedly scanning JARs for a class that isn't there.



I intend to wok on a patch for Tomcat that will add caching that should 
speed things up considerably. I hope to have something for Eric to test 
today but it might take me until tomorrow as I have a few other time 
critical things fighting to get tot he top of my TODO list at the moment.



Moving the JDBC driver JARs from WEB-INF/lib to $CATALINA_BASE/lib may 
also be a short-term fix but is likely to create problems if the same 
JAR ever exists in both locations at the same time.



Mark

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

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

2024-05-29 Thread Mark Thomas


On 28/05/2024 16:26, Eric Robinson wrote:




Took a bunch of thread and heap dumps during today's painful debacle. Will send 
a link to those as soon as I can.


Thanks. I have them. I have taken a look and I am starting to form a 
theory. To help with that I have a couple of questions.


1. Could you tell me where the JDBC driver JAR is located. Is it in 
WEB-INF/lib for the web application(s) or is it in $CATALINA_BASE/lib ?


2. How big is WEB-INF/lib for the web application(s)? How many JAR files 
and what is the total size on disk of that directory?


3. Would you be prepared to run Tomcat in production with a binary patch 
(against 9.0.80). This would involve placing one or more class files in 
the right directory structure under $CATALINA_BASE/lib either to collect 
additional debug logging or to test a potential fix.




Mark

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

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

2024-05-28 Thread Mark Thomas

Hi Eric,

Follow-up observsations and comments in-line.

What time does this problem start?

It typically starts around 9:15 am EDT and goes until around 10:30 am.

Does that match the time of highest request load from the customer?
Rather than a spike, I'm wondering if the problem is triggered once load
exceeds some threshold.

We finished and implemented the script yesterday, so today will be the first
day that it produces results. It watches the catalina.out file for stuck thread
detection warnings. When the number of stuck threads exceeds a threshold, then
it starts doing thread dumps every 60 seconds until the counts drops back down
below the threshold. The users typically do not complain of slowness until the
stuck thread count exceeds 20, and during that time the threads often take up
to a minute or more to complete. It's too late today to change the timings, but
if it does not produce any actionable intel, we can adjust them tonight.

Lets see what that produces and go from there.

The vendor claims that the feature uses a different server and does not send
requests to the slow ones, so it has been re-enabled at the customer's request.
We may ask them to disable it again until we get this issue resolved.

Noted.

This customer sends about 1.5 million requests to each load-balanced server
during a typical production day. Most other customers send much less, often
only a fraction of that. However, at least one customer sends about 2 million
to the same server, and they don't see the problem. (I will check if they have
the AI feature enabled.)

Hmm. Whether that other customer has the AI feature enabled would be an
interesting data point.

Can we see the full stack trace please.

Here's one example.

java.lang.Throwable
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1252)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)

That is *very* interesting. That is the start of a synch block in the
class loader. It should complete quickly. The full thread dump should
tell us what is holding the lock. If we are lucky we'll be able to tell
why the lock is being held for so long.

We might need to reduce the time between thread dumps to figure out what
the thread that is blocking everything is doing. We'll see.

The app has DB connection details in two places. First, it uses a database
connection string in a .properties file, as follows. This string handles most
connections to the DB.

mobiledoc.DBUrl=jdbc:mysql://ha52a:5791
mobiledoc.DBName=mobiledoc_791?useSSL=false&zeroDateTimeBehavior=round&jdbcCompliantTruncation=false&cacheServerConfiguration=true&dumpQueriesOnException=true&tinyInt1isBit=false&useOldAliasMetadataBehavior=true&dontTrackOpenResources=true
mobiledoc.DBUser=
mobiledoc.DBPassword=

OK. That seems unlikely to be using connection pooling although the
application might be pooling internally.

It also has second DB config specifically for a drug database.

c:\out.log

INSERT_CONTEXT_FACTORY
INSERT_JNDI_URL
INSERT_USER_NAME
INSERT_PASSWORD
INSERT_LOOKUP_NAME
com.mysql.jdbc.Driver

jdbc:mysql://dbclust54:5791/medispan?sessionVariables=wait_timeout=28800,interactive_timeout=28800
redacted
redacted
10
5000

true
0
1800

Hmm. There is a pool size setting there but we can't tell if it is being
used.

Is that Tomcat 9.0.80 as provided by the ASF?

An explicit answer to this question would be helpful.

In terms of the way forward, we need to see to thread dumps when the
problem is happening to figure out where the blockage is happening and
(hopefully) why.

Mark

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

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

2024-05-28 Thread Mark Thomas

Hi Eric,

I have a some follow-up questions in-line. I have also read the other
messages in this thread and added a couple of additional questions based
on what I read in those threads.

On 26/05/2024 02:58, Eric Robinson wrote:

One of our hosting customers is a medical practice using a commercial EMR
running on tomcat+mysql. It has operated well for over a year, but users have
suddenly begun experiencing slowness for about an hour at the same time every
day.

What time does this problem start?

Does it occur every day of the week including weekends?

How does the slowness correlate to:
- request volume
- requests to any particular URL(s)?
- requests from any particular client IP?
- any other attribute of the request?

(I'm trying to see if there is something about the requests that
triggers the issue.)

During the slow times, we've done all the usual troubleshooting to catch the
problem in the act. The servers have plenty of power and are not overworked.
There are no slow database queries. Network connectivity is solid. Tomcat has
plenty of memory. The numbers of database connections, threads, questions,
queries, etc., remain steady, without spikes. There is no unusual disk latency.
We have not found any maintenance tasks running during that timeframe.

I would usually suggest taking three thread dumps approximately 5s apart
and then diffing them to try and spot "slow moving" threads.

I see you have scripted trigger a thread dump when the slowness hits. If
you haven't already, please configure it to capture (at least) 3 dumps
~5 seconds apart.

(If we can spot the slow moving threads we might be able to identify
what it is that makes them slow moving.)

The customer has another load-balanced tomcat instance on a different physical
server, and the problem happens on that one, too. The servers were upgraded
with a new kernel and packages on 4/5/24, but the issue did not appear until
5/6/24. The vendor enabled a new feature in the customer's software, and the
problem appeared the next day, but they subsequently disabled the feature, and
(reportedly) the problem did not go away.

Have you confirmed that the feature really is disabled? Or was it just
hidden?

Has this feature been enabled for any other customers? If yes, have they
experienced similar issues?

(It is suspicious that the issue occurred after the feature was
disabled. I wonder if some elements of that change (e.g. a database
change) are still in place and causing issues.)

It is worth mentioning that the servers are multi-tenanted, with other
customers running the same medical application, but the others do not
experience the slowdowns, even though they are on the same servers.

How does this customer compare, in terms of volume of requests, to other
customers that are not experiencing this issue.

Is there anything unique or special about the customer experiencing the
issue? Do they have some custom settings no-one else uses?

(I am trying to figure out if the issue is load related, customer
specific or something else).

There are no unusual errors in the tomcat or database server logs, EXCEPT this
one: Java.sql.DriverManager.getConnection

Can we see the full stack trace please.

During the periods of slowness, we see lots of those errors along with a large
spike in the number of stuck tomcat threads (from 1 or 2 to as high as 100). It
seems obvious that the threads are stuck because tomcat is waiting on a
connection to the database. However, tcpdump shows that connectivity to the
database is perfect at the network and application layers. There are no
unanswered SYNs, no retransmissions, no half-open connections, no failures to
allocate TCP ports, no conntrack messages, and no other indications of system
resource exhaustion. Every time tomcat requests a connection to the DB, it
completes in less than 1 ms. Ten thousand connection attempts completed
successfully in about 15 seconds, with zero failures.

It sounds like things might be getting stuck somewhere in or near the
JDBC driver.

Can you provide the exact version of the JDBC driver you are using?

Can you provide the full database configuration from context.xml (or
wherever it is configured). Please redact sensitive information such as
passwords.

We are forced to conclude that some database connection requests are being
initiated but are not being sent on the wire. The problem seems to be in the
interaction between tomcat and the database driver, or in the driver itself.

I agree.

Unfortunately, the application vendor is taking the "it's your infrastructure"
position without providing any evidence or offering suggestions for configuration changes,

I'm sorry to hear that. We'll do what we can to help.

other than to deploy more tomcat instances, which is just shooting in the dark.
They don't know why the software is throwing
java.sql.DriverManager.getConnection errors (even though it's their code), and
they'

Re: Deployment using directory

2024-05-25 Thread Mark Thomas


On 24/05/2024 19:28, Brandie Nickey wrote:

Hi all,

I am curious if there are any cons to deploying a webapp without using a war 
file.


None.

If you deploy a WAR Tomcat will (by default) unpack it and run it from 
the unpacked directory anyway. If you configure Tomcat to run from the 
packed WAR you will get a small performance hit.



 Our web app has just always traditionally been 'unzipped' as a set of folders 
within the Tomcat/webapps/ROOT directory.  However I have been doing some 
troubleshooting using procmon.exe from Sysinternals and it appears that tomcat 
is constantly looking for Root.war file.


Define constantly. I'd expect Tomcat to be checking for a WAR file every 
~15s if autodeploy is enabled.



Not sure if I have something misconfigured or this behavior is just normal?  
The app will start up but does have some issues with loading all features  
(takes 2+ hours) .


If the app is taking 2 hours to start then the app has some serious issues.


Running Tomcat 8.0.43.


Tomcat 8.0.x reached end of support on 30 June 2018.

Tomcat 8.5.x (that replaced 8.0.x) reached end of life on 31 March 2024.

You need to upgrade to at least 9.0.x ASAP. I'd suggest a quick upgrade 
to 9.0.x and then start looking at moving to 10.1.x or even 11.0.x but 
that is a bigger job due to the Java EE -> Jskarta EE repackaging.


Mark

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

Re: PersistentManager and ClassNotFoundException

2024-05-25 Thread Mark Thomas


On 24/05/2024 14:31, Jakub Królikowski wrote:




Hi Mark,
It seems to me that this can be tested on any application.
In Tomcat 10.1, if any session attribute is an instance of a new public
class (unknown to Tomcat and to Tomcat class loader), implementing
java.io.Serializable,
then on reloading the application PersistanceManager (configured as in the
first message) crashes with ClassNotFoundException. StandardManager works.
I don't know if this problem occurred in earlier versions of Tomcat.

If you fail to reproduce this bug, let me know, I will prepare a simple web
app.

Best regards,

Jakub


Jakub,

The chances of a committer looking at the issue you are seeing are 
significantly higher if you provide a test case that demonstrates the 
issue rather than expecting a committer to write a test case for you 
based on your description.


Mark


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

Re: PersistentManager and ClassNotFoundException

2024-05-24 Thread Mark Thomas

Can you provide the simplest web application (with source) that 
replications the problem?


Mark


On 23/05/2024 23:45, Jakub Królikowski wrote:

Hi,

I'm working with Tomcat 10.1.

When a user starts using the store in my web application, I save the
ShopCart object on the "cart" session attribute.
I want the "cart" attributes to return to the session after restarting the
app.


To enable session persistence I added



to the Context. It loads the StandardManager.

And this works fine - after reload / restart the object "ShopCart" is back
in the session.



I want to experiment with PersistentManager. Tomcat docs says: "
The persistence across restarts provided by the *StandardManager* is a
simpler implementation than that provided by the *PersistentManager*. If
robust, production quality persistence across restarts is required then the
*PersistentManager* should be used with an appropriate configuration.

"

I hope for a Listener of deserialization of the session attributes.

The new Manager configuration looks like this:







But it doesn't work. After restart I get this exception:


java.lang.ClassNotFoundException: ShopCart

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1332)

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1144)

at java.base/java.lang.Class.forName0(Native Method)

at java.base/java.lang.Class.forName(Class.java:534)

at java.base/java.lang.Class.forName(Class.java:513)

at
org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:158)

at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2061)

at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1927)

at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2252)

at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1762)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:540)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:498)

at
org.apache.catalina.session.StandardSession.doReadObject(StandardSession.java:1198)

at
org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:831)

at org.apache.catalina.session.FileStore.load(FileStore.java:203)

at org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:138)

at
org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:409)

at
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:587)

at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4787)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1172)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1154)

at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)

at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)

at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)

at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)

at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)

at java.base/java.lang.Thread.run(Thread.java:1583)


I guess this means that the two managers use ClassLoader differently.
How to get the PersistentManager to work in this case?

Best regards,
--
Jakub Królikowski



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

Re: Security Constraints and Session Timeout

2024-05-24 Thread Mark Thomas


On 23/05/2024 17:01, Jerry Malcolm wrote:
I have some servlets that I can't put security constraints on at the 
web.xml level.  However, deep down in the code there are some places 
that I need a user to be logged in.  My overall UI ensures this all 
works by having certain JSPs with constraints that force the user to log 
in before getting to the servlet.  But if the user spends too much time 
interacting with the servlet and not reloading one of the pages that 
require a login, the session will timeout, and the user is now buried in 
one of the servlets, and I've lost the session/userprincipal.  It 
appears that interacting with a servlet that has no constraints does not 
reset the session timer.  Is that correct, or am I seeing it wrong?  I 
know the easy answer would be to add a constraint requiring login to 
access the servlet.  But with the current design, that's not going to 
work. Is there something I can do in the servlet and/or servlet config 
in web.xml to force servlet access to keep resetting the session timer 
so it won't expire without having to put role constraints directly on 
the servlet?


Just calling HttpServletRequest.getSession(false) from the Servlet 
should be sufficient.


Note you can monitor the expiration time for sessions using the Manager 
application. That might be helpful in testing.


Mark

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

Re: After Windows Server Restart, tomcat generating New JSESSIONID even with <%@ page session="false" %>

2024-05-07 Thread Mark Thomas


On 06/05/2024 11:05, Hamdan Khan wrote:

Hello everyone,

We're having a problem with Tomcat on Windows servers. It only happens when:

Tomcat is running as a service (automatically started by Windows).
The Windows server automatically restarts for updates.
After the restart, Tomcat starts creating new session IDs for
every request,


That suggests that the client isn't returning the session ID to Tomcat 
for the subsequent request. I'd be asking why that is the case.


Is there a reverse proxy in the mix?

Are you using sessions at all or are they completely disabled? If yes, 
which session manager are you using?



even though our jsp tells it not to.

<%@ page session="false" %>


That is just a single page and any page can potentially trigger session 
creation.



We can fix this by deleting temp and work files from Tomcat and restarting
the service ourselves.  However, this is a manual process, and we'd like to
find a more permanent solution.


It would be interesting to know if you need to clear both of these or 
whether clearing just one is sufficient to resolve the issue. That might 
narrow down potential root causes.



Can anyone help us understand why this might be happening?


I can't think of any way Tomcat would do this. This feels more like an 
application issue at this point.



Or what logs to
configure and monitor.


My preference would always be to attach an IDE and use remote debugging 
but that probably isn't an option in production.


You could try attaching a profiler and recording object allocations. 
That should show you where/how sessions are being created.


The minimally invasive option would probably be to add an 
HttpSessionListener to your application that logs the current stack 
trace every time a session is created.



Version of Tomcat is Tomcat-9.0.83

To emphasize we are not able to reproduce this in our local computer it
only happens to the longrunning production servers.


If you manually reboot the production servers (without clearing out work 
or temp) can you trigger the issue?


Mark

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

Re: missing headers

2024-05-02 Thread Mark Thomas

On 02/05/2024 06:15, Piyush Sharma wrote:

Hi,

How to forward custom headers from frontend tomcat to backend tomcat witn
mod_jk?

When using mod_jk the front end is always httpd, not Tomcat.

You don't need to do anything. mod_jk passes all the http headers it
receives.

*Scenario :*

1. APP1 : Apache (mod_jk) + Tomcat
2. APP2 : Apache (mod_jk) + Tomcat

Now, when a user accesses APP1 it add fews headers via SSO app user details
etc..
I can see in Tomcat logs as by adding filters. Now when the request goes to
APP2 (backend Tomcat via Apache), it drops those custom headers.

That sounds like a client issue. Client sends request to app1 and
receives some custom headers. If you want those headers sent to app2
then that is a client issue, not a Tomcat issue.

I came to
know that *mod_jk does not use the http protocol to talk to the tomcat
server.* Is there any way to forward all the custom headers from frontend
application to backend applications.

This already happens.

https://stackoverflow.com/questions/18998715/http-response-header-not-coming-with-apache-tomcat-connection-using-mod-jk

There is a fair amount of nonsense in both the question and some of the
responses.

It would be a lot easier to help you if you provided a lot more
information. For example:

- httpd version
- tomcat version
- mod_jk version
- httpd configuration
- tomcat configuration
- mod_jk configuration
- sample request as sent by the client
- sample request as received by Tomcat
- sample response as sent by Tomcat
- sample response as received by the client
- the previous 4 to be provided both by going via the reverse proxy and
by going directly to Tomcat

Mark

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

Re: Monitoring and Tuning Tomcat

2024-05-01 Thread Mark Thomas


On 30/04/2024 21:24, Jerry Malcolm wrote:
I'm trying to optimize my instance, CPU, tuning, and size requirements 
for Tomcat.  It's easy to see CPU usage.  But this TC instance is 
running a lot of microservices that are often in and out fairly 
quickly.  So there can be a huge number of requests coming in.  I'm not 
sure that CPU starving is my biggest concern. I'm more interested is 
getting an understanding of TC front end bottlenecks and also JDBC data 
connection bottlenecks.   So I need a bit of education.   Am I correct 
that maxThreads on the connector throttles the number of requests that 
can come in at one time?


Not quite.

maxThreads is the maximum number of concurrent requests that Tomcat can 
process. This excludes:

- connections in keep-alive
- requests that have entered async mode and have exited the original
  container thread
This includes:
- multiple requests received on a single HTTP/2 connection

The maximum number of connections is controlled by maxConnections.

And connectionTimeout is the time to wait to 
get in the door if threads are maxed out before giving up and failing, 
correct?


No. It is the maximum time Tomcat will wait from the point the 
connection is accepted to reading the first byte of data.


I'd really like to track total threads in use and then track 
wait time if total threads are maxed out.  Likewise, with database 
connections.


You can track the status of the thread pool but wait time isn't 
available as Tomcat has no visibility into the accept queue (see 
acceptCount). Your OS might provide some stats here.


  I'd like to monitor the jdbc connection pool as well and 
see when and where the code is having to wait for a db connection and 
how long the average wait is.  I assume there are jms hooks to monitor 
this?


Correct. You probably want the stats from the o.a.t.u.dbcp.pool2.impl 
package.


But I don't want to reinvent the wheel.  Are there tools out there 
to assist with this already? Thx


Generally, I start with a profiler when looking at questions like this. 
I use YourKit because they given me a free copy to use for Tomcat 
development but there are lots of different profilers available.


Mark

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

Re: Disabling OPTIONS HTTP method with * path

2024-05-01 Thread Mark Thomas


On 30/04/2024 19:56, Oleg Frenkel wrote:

This issue exists in 9.0.88 and 10.1.23.

I am looking to disable the following HTTP request (note 'OPTIONS *' in the 
request):


Why?


Please confirm if this is a bug in Tomcat or if I am missing something in 
Tomcat configuration.


Neither. Tomcat is working as designed.

Mark

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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1014 matches

Mail list logo