Re: Rate Limiting support in Tomcat 9.x

[Mark Thomas]

On 22/05/2023 21:16, Amit Pande wrote:

Hello,

https://tomcat.apache.org/  I see rate limiting support added in Tomcat 10.1.9 .

(Side note: The Apache Tomcat Project is proud to announce the release of 
version 10.1.8 of Apache Tomcat - I think it should be 10.1.9)


Thanks. The typo has been fixed.


Are there any plans to add this filter in 9.x? Could an enhancement request be 
raised to get this in next Tomcat 9.x release?


It is already included in 9.0.x (and 8.5.x).

Mark

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

Re: Tomcat connection pool 9.0.52 uses more then configured maxActive connections

[Mark Thomas]

On 22/05/2023 09:45, Stefan López Romero wrote:

Hello,

I have the problem that the Tomcat connection pool uses more than the 
maxActive connections. In my Dropwizard application I have configured a 
maxSize of 30, but I found the following message in the logs.


Timeout: Pool empty. Unable to fetch a connection in 15 seconds, none 
available[size:31; busy:31; idle:0; lastwait:15000]


This seems to be related to a high pressure on the DB. In the DB logs I 
also found some connection issues


The code in the PooledConnection class does not seem to be completely 
bulletproof, because there can't be only two threads that have gone 
through the first if-two, or am I wrong?


Given that size is an AtomicInteger, I don't see a sequence of calls 
from multiple threads that could result in more than maxActive 
connections being created.


Also, it would have saved me some time if you had referenced the correct 
class. The quoted code is part of ConnectionPool, not PooledConnection.



//if we get here, see if we need to create one
//this is not 100% accurate since it doesn't use a shared
//atomic variable - a connection can become idle while we are creating
//a new connection
if (size.get() < getPoolProperties().getMaxActive()) {
//atomic duplicate check
if (size.addAndGet(1) > getPoolProperties().getMaxActive()) {
//if we got here, two threads passed through the first if
size.decrementAndGet();
} else {
//create a connection, we're below the limit
return createConnection(now, con, username, password);
}
} //end if

In the end, this problem causes all my available DB connections to be 
used up and my application to fail.


Is this a known problem? Is there a workaround?


At worst, this appears to be an off-by-one error either in the error 
message or the connection counting logic. Even with that addressed, it 
looks as if either the application has a connection leak or you need a 
bigger connection pool to support the required load.


Mark

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

[SECURITY] CVE-2023-28709 Apache Tomcat - Fix for CVE-2023-24998 was incomplete

[Mark Thomas]

CVE-2023-28709 Apache Tomcat - Fix for CVE-2023-24998 was incomplete

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M2 to 11.0.0-M4
Apache Tomcat 10.1.5 to 10.1.7
Apache Tomcat 9.0.71 to 9.0.73
Apache Tomcat 8.5.85 to 8.5.87

Description:
The fix for CVE-2023-24998 was incomplete. If non-default HTTP connector 
settings were used such that the maxParameterCount could be reached 
using query string parameters and a request was submitted that supplied 
exactly maxParameterCount parameters in the query string, the limit for 
uploaded request parts could be bypassed with the potential for a denial 
of service to occur.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M5 or later
- Upgrade to Apache Tomcat 10.1.8 or later
- Upgrade to Apache Tomcat 9.0.74 or later
- Upgrade to Apache Tomcat 8.5.88 or later

Credit:
This issue was identified by Chenwei Jiang, Chenfeng Nie and Yue Yang 
from the Huawei Nebula Security Lab


History:
2023-05-22 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
[4] https://tomcat.apache.org/security-8.html

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

Re: Best Practice to Upgrade Apache Tomcat from 9.0.56 to 9.0.74

[Mark Thomas]

18 May 2023 06:06:04 Meltron Kendrick :


I created a "jar" file using WinRAR -- but no go ---

Got the following error message...

"Error: Could not find or load main class
org.apache.catalina.util.ServerInfo"

Any ideas on HOW TO properly do this?


Start with an official Tomcat release that doesn't have this problem. If 
the version numbers are broken, what else is?


If you really want to continue down this path, then don't try editing the 
JAR. Rather, override the resource.


Under $CATALINA_HOME/lib create the directory structure 
org/apache/catalina/util and then extract ServerInfo.properties to that 
directory. Edit the file. Start Tomcat. Tomcat will use the extracted 
file in preference to the one in the JAR.


Mark






On Wed, May 17, 2023 at 9:58 PM Meltron Kendrick 


wrote:

I was able to DECOMPRESS the .jar file -- using 7-zip -- and edited 
the
org/apache/catalina/util/ServerInfo.properties file to the proper 
version

and date info...

Now I need to COMPRESS everything with the updated
org/apache/catalina/util/ServerInfo.properties file added back into 
the

.jar file...


On Wed, May 17, 2023 at 1:43 AM Meltron Kendrick <
meltronkendr...@gmail.com> wrote:


Thank you Chuck!

What is the best way to go about updating the 3 lines to accurately
reflect the proper version details?



On Tue, May 16, 2023 at 9:08 PM Chuck Caldarale  
wrote:




On 2023-05-16, at 17:02, Meltron Kendrick 


wrote:


I am trying to get these fields to UPDATE properly...

ESPECIALLY THESE 3 ---
(but all of them would be nice)

Server version:  Secure Web Server
Server built: Jan 01 2000 00:00:00 UTC
Server number: 1.0.0.0


This information comes from this file inside lib/catalina.jar:
    org/apache/catalina/util/ServerInfo.properties

Whoever built your Tomcat distribution changed the contents of that 
file

when constructing the package. Using an unadulterated download from
tomcat.apache.org  results in something
similar to the following when running the version command:

Server version: Apache Tomcat/11.0.0-M6
Server built:   May 3 2023 17:28:15 UTC
Server number:  11.0.0.0
OS Name:    Mac OS X
OS Version: 13.3.1
Architecture:   aarch64
JVM Version:    18.0.1.1+2-6
JVM Vendor: Oracle Corporation

  - Chuck

--

==
Blessed Regards,

Meltron Kendrick
Sr. Systems Engineer
Linux * Windows * Cloud Computing * Security

LinkedIn: http://www.linkedin.com/in/meltronkendrick

Mobile: (512) 233-9176
Email: meltronkendr...@gmail.com


--
==
Blessed Regards,

Meltron Kendrick
Sr. Systems Engineer
Linux * Windows * Cloud Computing * Security

LinkedIn: http://www.linkedin.com/in/meltronkendrick

Mobile: (512) 233-9176
Email: meltronkendr...@gmail.com


--
==
Blessed Regards,

Meltron Kendrick
Sr. Systems Engineer
Linux * Windows * Cloud Computing * Security

LinkedIn: http://www.linkedin.com/in/meltronkendrick

Mobile: (512) 233-9176> Email: meltronkendr...@gmail.com


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

Re: unsupported source vm 17?

[Mark Thomas]

On 17/05/2023 11:58, Holger Klawitter wrote:

Hi there,

I am using tomcat 9.0.73 along with jdk 17.0.7+8.
I have set up tomcat to support jdk 17 on all jsp pages.

 
 jsp
 org.apache.jasper.servlet.JspServlet
 
 compilerSourceVM
 17
 
 
 compilerTargetVM
 17
 
 
 fork
 false
 
 
 xpoweredBy
 false
 
 3
 

In the logfiles I notice the following Warning:

17-May-2023 11:53:37.171 WARNUNG [http-nio-80-exec-10] 
org.apache.jasper.compiler.JDTCompiler.generateClass Unsupported source VM [17] 
requested, using [16]

Does this mean that tomcat/jasper is not fully supporting jdk17 at this point?


No.

Tomcat 9.0.x is required by the Servlet specification to be built for 
Java 8. Version 4.20 (also know as version 3.26.0) of the Eclipse JDT 
compiler is the latest version that works with Java 8. It supports up to 
Java 16.


If you want to use JSPs on Tomcat 9.0.x with a Java version greater than 
16 you need to replace $CATALINA_HOME/lib/ecj-4.20.jar with a newer version.


Newer JARs are available from Eclipse or Maven Central:

https://search.maven.org/artifact/org.eclipse.jdt/ecj

Tomcat 10.1.x currently ships with the latest JAR.

Mark

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

Re: Java G1 GC creating less garbage and taking more time in mixed GC phase

[Mark Thomas]

On 16/05/2023 08:50, M Venkata Pratap M wrote:

Hi ,
1. Thanks for the reply , attached screenshots for 9.0.62 heapdump.


The list doesn't support attachments.

A single thread dump isn't much use.

You need to take thread dumps for each scenario and compare them. Once 
you have identified the significant differences, that should provide the 
basis for a discussion of why those differences are present and the 
impact they have.


Mark


2. http2.Stream objects is taking around 28MB. Also InputBuffer was 
occupying more memory  around 235MB. was it normal.
3. In our application we are receiving 800 json requests per second an 
average of 3KB data each request and will respond with in a second.
4. All the tomcat settings are defaults , Overall anything suspicious 
from the screenshots.

Thanks & Regards,
Venkat.

-Original Message-
From: Mark Thomas 
Sent: 16 May 2023 12:44
To: users@tomcat.apache.org
Subject: Re: Java G1 GC creating less garbage and taking more time in mixed GC 
phase



On 16/05/2023 05:12, M Venkata Pratap M wrote:

Hi,

1.  We are using Http2 , When compared to 9.0.38 tomcat version , 9.0.62 
version is creating less garbage and taking  more time(2 to 5 seconds) in 
garbage collection during mixed GC phase.
2.  Are there any recommendation GC setting. Has any one observed these 
kind of problem.


Time spent in GC is generally proportional to the size of the live objects on 
the heap. I'd suggest comparing heap dumps from 9.0.38 and
9.0.62 to see what is different.

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: Java G1 GC creating less garbage and taking more time in mixed GC phase

[Mark Thomas]

On 16/05/2023 05:12, M Venkata Pratap M wrote:

Hi,

   1.  We are using Http2 , When compared to 9.0.38 tomcat version , 9.0.62 
version is creating less garbage and taking  more time(2 to 5 seconds) in 
garbage collection during mixed GC phase.
   2.  Are there any recommendation GC setting. Has any one observed these kind 
of problem.


Time spent in GC is generally proportional to the size of the live 
objects on the heap. I'd suggest comparing heap dumps from 9.0.38 and 
9.0.62 to see what is different.


Mark

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

Re: Setting service parameters not work in Tomcat 8.5.85+

[Mark Thomas]

On 10/05/2023 22:06, Gilles Maurice wrote:

Hello,

Our product currently uses Tomcat 8.5.83. We wanted to upgrade to Tomcat 
8.5.88 but our product fails to start up with this version.


 From my research I was able to determine the following facts:
- Upgrade to 8.5.84 works fine
- Upgrade to 8.5.85+ fails
- Our product uses "tomcat8.exe //US/vlm" to update the service 
parameters (vlm is the internal name of our product)
- with 8.5.85, calling the following command works fine: tomcat8.exe 
//US/vlm --Description myDescription
- setting java parameters don't work however, for example this command 
fails: tomcat8.exe //US/vlm --JvmMs 128
- when running the command above, tomcat8.exe does not display an error 
but the service is not updated
- the documentation at 
https://tomcat.apache.org/tomcat-8.5-doc/windows-service-howto.html 
indicates that the java update parameters are not set when in exe mode 
but ours is in jvm mode. For example, the following command will not set 
the JvmMs value: tomcat8.exe //US/vlm --Jvm auto --StartMode jvm 
--StopMode jvm --JvmMs 128


Does anyone have any info on how to get around this?


I am unable to recreate the problem described.

tomcat8.exe //US/Tomcat8 --JvmMs 128

works for me with a clean Tomcat installation.

How are you determining if the service is updated?

Otherwise, can someone direct me to the source code for tomcat8.exe so I 
can see if I can find the cause of this issue myself?


You want Commons Daemon. Tomcat 8.5.85 upgraded from 1.3.2 to 1.3.3.

https://github.com/apache/commons-daemon

Tomcat8.exe is a renamed prunsrv.exe

Tomcat8w.exe is a renamed prunmgr.exe


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-M6 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M6 (alpha).

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-M6 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-M5 include:


- Various improvements to access logging.

- Remove support for the HTTP Connector settings rejectIllegalHeader and
  allowHostHeaderMismatch. These are now hard-coded to the previous
  defaults.

- Update the packaged version of the Tomcat Migration Tool for Jakarta
  EE to 1.0.7.

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: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

[Mark Thomas]

On 08/05/2023 22:04, Christopher Schultz wrote:

On 5/8/23 10:39, Mark Thomas wrote:




The port the client connects to is irrelevant. All that matters is the 
host in the request line and the host header.


1. The host header MUST be present
2. If a host is present in the request line it MUST be identical (host 
and port) to the host header.


nb the spec says that the URL takes precedence if there is a mismatch, 
but when setting allowHostHeaderMismatch="false" (the current default), 
then Tomcat is being stricter than the spec.


That is not correct. The two requirements stated above have been RFC 
"MUST" requirements since 2014.


RFC 2616 (June 1999) stated that any host in the request line takes 
precedence.


RFC 7230 (June 2014) stated that any host in the request line MUST match 
the host header although there is also language that suggests they might 
be different.


RFC 9112 (June 2022) states that any host in the request line MUST match 
the host header.


Mark

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

Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

[Mark Thomas]

On 08/05/2023 13:52, Alvaro Garay wrote:

Hi Mark,

In the example above...the port remains the same (8143). How is it different?


GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1

The host is "myhostname.company.com"

Host: myhostname.company.com:8143

The host is "myhostname.company.com:8143"

"myhostname.company.com" != "myhostname.company.com:8143"

The port the client connects to is irrelevant. All that matters is the 
host in the request line and the host header.


1. The host header MUST be present
2. If a host is present in the request line it MUST be identical (host 
and port) to the host header.


Mark



________
From: Mark Thomas 
Sent: Friday, May 5, 2023 4:56 PM
To: Tomcat Users List 
Subject: [EXTERNAL] Re: Question in regards to the Connector allowHostHeaderMismatch when 
it is set to "false"


5 May 2023 18:21:02 Alvaro Garay :


Hi,


Tomcat version: 9.0.73

Operating system: Unix z/OS System



I have a question in regard to the Connector attribute
allowHostHeaderMismatch=false which checks the request line is
consistent with the Host Header.

So in this scenario, I have the request line using the absolute path
with a conflicting host header. The response is 400 Bad Request from
Tomcat, which makes sense.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: facebook.com


If I define a valid host header now, then the request is a success. So
all is good.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: myhostname.company.com

telnet 1.1.1.1 8143
GET http://1.1.1.1/api/v1/endpoint  HTTP/1.1
Host: 1.1.1.1

However, as soon as I define a port number in the host header with
syntax : then I get 400 Bad Request from Tomcat.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: myhostname.company.com:8143

HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 762
Date: Fri, 05 May 2023 15:27:09 GMT
Connection: close

HTTP Status 400 \u2013 Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 \u2013 Bad RequestType
Status ReportDescription The server cannot or will not
process the request due to something that is perceived to be a client
error (e.g., malformed request syntax, invalid request message framing,
or deceptive request routing).Apache
Tomcat/9.0.73

This request should be allowed right?


No. Different port means a different host so Tomcat correctly rejects the
request.

Mark

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




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

Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

[Mark Thomas]

5 May 2023 18:21:02 Alvaro Garay :


Hi,


Tomcat version: 9.0.73

Operating system: Unix z/OS System



I have a question in regard to the Connector attribute 
allowHostHeaderMismatch=false which checks the request line is 
consistent with the Host Header.


So in this scenario, I have the request line using the absolute path 
with a conflicting host header. The response is 400 Bad Request from 
Tomcat, which makes sense.


telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: facebook.com


If I define a valid host header now, then the request is a success. So 
all is good.


telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com

telnet 1.1.1.1 8143
GET http://1.1.1.1/api/v1/endpoint HTTP/1.1
Host: 1.1.1.1

However, as soon as I define a port number in the host header with 
syntax : then I get 400 Bad Request from Tomcat.


telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com:8143

HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 762
Date: Fri, 05 May 2023 15:27:09 GMT
Connection: close

HTTP Status 400 \u2013 Bad 
Requestbody 
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b 
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a 
{color:black;} .line 
{height:1px;background-color:#525D76;border:none;}HTTP 
Status 400 \u2013 Bad RequestType 
Status ReportDescription The server cannot or will not 
process the request due to something that is perceived to be a client 
error (e.g., malformed request syntax, invalid request message framing, 
or deceptive request routing).Apache 
Tomcat/9.0.73


This request should be allowed right?


No. Different port means a different host so Tomcat correctly rejects the 
request.


Mark

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