[jira] [Resolved] (DAEMON-431) prunsrv crashes when stopping most windows versions

[Mark Thomas (Jira)]

 [ 
https://issues.apache.org/jira/browse/DAEMON-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved DAEMON-431.

Resolution: Cannot Reproduce

No further information provided after an extended period of time.

> prunsrv crashes when stopping most windows versions
> ---
>
> Key: DAEMON-431
> URL: https://issues.apache.org/jira/browse/DAEMON-431
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: prunsrv
>Affects Versions: 1.2.4
> Environment: windows 10 fully patched.
>Reporter: scott williams
>Priority: Major
>
> Crashes when stopping every time. This is from win10 fully patched, but also 
> crashes on server 2012 and 2016 older patched. 
>  
> Faulting application name: wildfly-service.exe, version: 1.2.4.0, time stamp: 
> 0x600011df
> Faulting module name: ntdll.dll, version: 10.0.19041.789, time stamp: 
> 0x4f929756
> Exception code: 0xc374
> Fault offset: 0x000ff099
> Faulting process id: 0x14d4
> Faulting application start time: 0x01d6ff2eb6330c32
> Faulting application path: C:\web\bin\service\amd64\wildfly-service.exe
> Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
> Report Id: f2389cdb-df37-4a9c-b862-4399161457ea
> Faulting package full name: 
> Faulting package-relative application ID:



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (DAEMON-449) Prunsrv fails to stop Open Liberty Windows service

[Mark Thomas (Jira)]

 [ 
https://issues.apache.org/jira/browse/DAEMON-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved DAEMON-449.

Resolution: Invalid

Given the lack of update for an extended period of time, I am assuming the 
issue was indeed that the batch file was exiting before the service was fully 
started.

If this is not the case, feel free to re-open but you'll need to provide a 
minimal test case that demonstrates the issue.

> Prunsrv fails to stop Open Liberty Windows service
> --
>
> Key: DAEMON-449
> URL: https://issues.apache.org/jira/browse/DAEMON-449
> Project: Commons Daemon
>  Issue Type: Bug
>  Components: prunsrv
>Affects Versions: 1.2.2
> Environment: I don't think the Windows version matters, but I am 
> using:
> Microsoft Windows [Version 10.0.19044.2006]
>Reporter: Jim Blye
>Priority: Major
> Attachments: commons-daemon.2022-09-28.log, 
> commons-daemon.2022-09-28_afterKillingServer.log, server.bat
>
>
> < *Update* . The reason the stop fails is because the start hasn't finished.  
> Prunsrv isn't waiting for the start to finish.  So in the Windows services 
> panel, the service appears to be started.  If you then click stop, it hangs 
> for a few minutes and fails to stop.  The state at this point in the Windows 
> services is "Stopping".  So you have to manually stop the process. >
> When Prunsrv is used to register Open Liberty 
> ([https://openliberty.io|https://openliberty.io/]) as a Windows Service, 
> stopping the service hangs randomly.
> *To recreate the problem:*
>   1) Download open liberty  ~300MB
>            
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-22.0.0.10.zip]
>   Alternatively, you could use just the liberty kernel ~10MB
>           
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-kernel-22.0.0.10.zip]
>   2) md C:\temp\openliberty
>    unzip openliberty-22.0.0.10.zip into C:\temp\openliberty
>   3) cd C:\temp\openliberty\wlp\bin
>   4) Run these two commands to make sure the server runs and to initialize 
> the environment:
>    server start
>    server stop
>    5) Register liberty as a service (parameter is case sensitive).  The 
> following command is used to invoke prunsrv to register the service using the 
> default name of defaultServer
>     server registerWinService
>     6)  Open the windows "services" app (services.msc).   Start and stop the 
> service until the stop hangs.  It usually doesn't take more than a couple of 
> tries.
>  
> *Details*
> The *server.bat* script registers the service like this:
> "C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe"  //IS//defaultServer 
> --Startup=manual --DisplayName="defaultServer" --Description="Open Liberty" 
> ++DependsOn=Tcpip 
> --LogPath="C:\temp\openliberty\wlp\usr\servers\defaultServer\logs" 
> --StdOutput=auto --StdError=auto --StartMode=exe 
> --StartPath="C:\temp\openliberty\wlp" 
> --StartImage="C:\temp\openliberty\wlp\bin\server.bat" 
> ++StartParams=start#defaultServer --StopMode=exe 
> --StopPath="C:\temp\openliberty\wlp" --StopImage="C:\temp\wlp\bin\server.bat" 
> ++StopParams=stop#defaultServer --ServiceUser=LocalSystem
> After registering the service you can look at its properties.  You will see:
>    Path to executable:
>    C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe //RS//defaultServer
> When I (and many of our customers) try to stop the service, it hangs.   At 
> that point, the server, named defaultServer is still up and running.  I can 
> send commands to the server.  For instance, I can execute a "server dump" 
> command. This sends the "dump" command to the server, and the server writes 
> information to a file.  I can also stop the server by executing "server 
> stop".  This sends the "stop" command to the server which causes the server 
> to stop.  When the server stops, the hanging Windows service stops as well.
> I have attached a *server.bat* which adds --LogLevel Debug to the prunsrv 
> commands and also *commons-daemon.2022-09-28.log* which demonstrates the 
> problem. It shows registering, starting, and stopping the service.  Finally, 
> I uploaded {*}commons-daemon.2022-09-28_afterKillingServer.log{*}, which is a 
> continuation of the other log file which shows the result of issuing the 
> server stop command to stop the server.
> Thanks for looking at this.
> Jim Blye



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (DAEMON-457) Tomcat9.exe crash in windows server 2016 and 2019 while updating service.

[Mark Thomas (Jira)]

 [ 
https://issues.apache.org/jira/browse/DAEMON-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Thomas resolved DAEMON-457.

Resolution: Cannot Reproduce

This can be re-opened if steps are provided to recreate this issue on a clean 
install of any currently supported Windows OS.

> Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
> -
>
> Key: DAEMON-457
> URL: https://issues.apache.org/jira/browse/DAEMON-457
> Project: Commons Daemon
>  Issue Type: Bug
>Affects Versions: 1.3.3
> Environment: Windows Server 2016 and 2019
>Reporter: Denish Kothadiya
>Priority: Critical
> Attachments: logs.zip
>
>
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We 
> have observer issue from Tomcat 9 version 9.0.70 and above. It was working 
> fine with Tomcat version 9.0.69.
> Environment details:
> OS: Windows server 2016 and 2019
> Disk space: More than 80 GB
> RAM: 8GB and more
> VC Redist x64: 14.29.30139.0
> Tomcat service details:
> JvmMs=512
> JvmMx=3076
> After creating tomcat service, We run below command to update service with 
> JavaOption9
> {code}
> Tomcat9 //US//Tomcat9 ++JvmOptions9 
> --add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED
> {code}
> Above command fails with below crash in EventViewer:
> Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp: 
> 0x637e7ca5
> Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp: 
> 0x65420ea4
> Exception code: 0xc374
> Fault offset: 0x000fa979
> Faulting process id: 0x298
> Faulting application start time: 0x01d967f65ac00dce
> Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe
> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8
> Faulting package full name: 
> Please let me know if you need any more details.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release Apache Tomcat 10.1.24

[Mark Thomas]

On 10/05/2024 11:22, Romain Manni-Bucau wrote:

Hi Christopher,

Is it possible to close the staging repo please (I get a 404)?


There is a typo in the VOTE email. The correct staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1495

Mark




Best,
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>


Le ven. 10 mai 2024 à 10:00, Mark Thomas  a écrit :


On 09/05/2024 19:12, Christopher Schultz wrote:


The proposed 10.1.24 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.1.24


Tests pass on Linux, Windows, MacOS (Intel) and MacOS (M1).

Build is cross platform reproducible (Linux / Windows).

Mark

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






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

Re: [VOTE] Release Apache Tomcat 10.1.24

[Mark Thomas]

On 09/05/2024 19:12, Christopher Schultz wrote:


The proposed 10.1.24 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.1.24


Tests pass on Linux, Windows, MacOS (Intel) and MacOS (M1).

Build is cross platform reproducible (Linux / Windows).

Mark

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

[ANN] Apache Tomcat 11.0.0-M20 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M20 (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-M20 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-M19 include:

- Add OpenSSL FFM classes to tomcat-embed-core.jar

- Refactor HTTP header parsing to use common parsing code and fix
  non-blocking reads of chunked request bodies including trailer fields

- Add more timescale options to AccessLogValve and
  ExtendedAccessLogValve

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

[ANN] Apache Tomcat 11.0.0-M20 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M20 (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-M20 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-M19 include:

- Add OpenSSL FFM classes to tomcat-embed-core.jar

- Refactor HTTP header parsing to use common parsing code and fix
  non-blocking reads of chunked request bodies including trailer fields

- Add more timescale options to AccessLogValve and
  ExtendedAccessLogValve

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

[VOTE][RESULT] Release Apache Tomcat 11.0.0-M20

[Mark Thomas]

The following votes were cast:

Binding:
+1: isapir, rjung, remm, markt

No other votes were cast.

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark

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

Re: Passing down arbitrary auth attributes down to Realm#authenticate()

[Mark Thomas]

On 07/05/2024 19:06, Michael Osipov wrote:

Folks,

I am working on a custom Authenticator and Realm where I need to pass 
down a custom value to Realm#authenticate(), more specially a value 
obtained from javax.security.auth.Subject#getPrivateCredentials(). 
Currently, there is no such facility in the interface. Any idea how to 
pass this down w/o touching the interface and w/o thread-local values? 
The only thing I can think of is a custom realm interface, but that 
means every realm needs to implement it...


Cast to your custom Realm in your custom Authenticator and then call any 
method you like? It sounds like the Realm and Authenticator are coupled 
together anyway.


Mark

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

Re: After Windows Server Restart, tomcat generating New JSESSIONID even with <%@ page session="false" %>

[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: [VOTE] Release Apache Tomcat 9.0.89

[Mark Thomas]

On 03/05/2024 21:37, Rémy Maucherat wrote:


The proposed 9.0.89 release is:
[ ] -1, Broken - do not release
[ ] +1, Stable - go ahead and release as 9.0.89


Tests pass on Linux, Windows, MacOS (Intel) and MacOS (M1).

Release is reproducible across platforms (Windows / Linux).

Mark

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

Re: [VOTE] Release Apache Tomcat 11.0.0-M20

[Mark Thomas]

On 03/05/2024 17:22, Mark Thomas wrote:


The proposed 11.0.0-M20 release is:
[ ] -1 Broken - do not release
[X] +1 Alpha  - go ahead and release as 11.0.0-M20


Tests pass on Linux, Windows, MacOS (Intel) and MacOS (M1).

Release is reproducible across platforms (Windows / Linux).

Mark

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

Re: Our ASN.1 parser

[Mark Thomas]

On 03/05/2024 11:01, Michael Osipov wrote:

On 2024/05/03 08:59:17 Mark Thomas wrote:





There have been discussions about a new tomcat-shaded JAR that would
provide all the shaded dependencies we use both internally and with the
migration tool. My general concern with that is the volume of code. The
migration tool is already a 1MB JAR - most of it shaded code that is
never going to be used. There are tradeoffs to make there that need a
longer discussion. It is likely to be one of the topics at the Tomcat
Security day in Bratislava.


What is the benefit of a single JAR here for the public?


Removes the duplication of BCEL. We have a cut down version for JAR 
scanning and a full version in the migration tool although we'd need to 
check performance as that was one of the reasons for the trimmed down 
version.


Simpler maintenance for us (just update versions in POM). May mean users 
get updated dependencies faster. That said, if there was a real need for 
an update we'd do it now anyway so...


Overall, probably more direct benefits for us than users. Users get the 
indirect benefits of us spending less time managing these dependencies.


Mark

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

Re: Our ASN.1 parser

[Mark Thomas]

On 03/05/2024 08:17, Michael Osipov wrote:

Hi folks,

currenly we have a minimalistic ASN.1 parser in the code tree w/o any 
testing


The ASN.1 parsing is covered by the test suite.


since it assumes that the passed byte array is properly encoded.


Correct. For the Tomcat use case it is sufficient that parsing fails if 
the input is invalid. It doesn't need to be particularly elegant at that 
point.


Now, I do have some X.509 related improvements which I'd like to bring 
upstream from my OSS project which I think will benefit everyone using 
X.509 (processing SAN from a client cert) in the enterprise world,


I'm not seeing much/any demand for this. Can you expand on the use case?

but 
this requires extending the parser. In fact, I have written a 
minimalistic parser for my use case with error handling and swapped for 
the Tomcat's one and most tests fail with ArrayIndexOutOfBoundsException 
because our code does not check anything.


How minimal is minimal? Lines of code / JAR size?

I do not want to write yet another full-blown parser, but do not also 
want to reinvent the wheel.

So several questions come to my mind:
1. Since I do also have other OSS components for Tomcat which do require 
an ASN.1 parser would our position be use our parser at your own risk or 
solve the problem yourself? I need only SEQUENCEs, tagged types. Nothing 
fancy.


What do you need that the current Tomcat implementation doesn't provide?

I think our position is use Tomcat's if it works for you. We'll consider 
PRs for enhancements if it doesn't. You are, of course, free to write 
you own or use another implementation.


2. Should we consider ditching it for something public and shade it like 
we do with other components? Apache Kerby ASN.1 is quite small and very 
decent.


Tomcat - 180 lines. Kerby - 100 kB JAR.

Kerby looks like a good choice if we want to go this route.

There have been discussions about a new tomcat-shaded JAR that would 
provide all the shaded dependencies we use both internally and with the 
migration tool. My general concern with that is the volume of code. The 
migration tool is already a 1MB JAR - most of it shaded code that is 
never going to be used. There are tradeoffs to make there that need a 
longer discussion. It is likely to be one of the topics at the Tomcat 
Security day in Bratislava.


Mark

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

Tagging May releases

[Mark Thomas]

Hi all,

Things are looking good for the May releases. I have a few things to 
back-port to 10.1.x and 9.0.x and then I'll start running my pre-release 
tests. Providing everything passes (and CI runs suggest they will) I'll 
tag 11.0.x - probably some time tomorrow.


Mark

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

Re: missing headers

[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

[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

[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

Re: Refactoring heads up

[Mark Thomas]

On 24/04/2024 17:52, Mark Thomas wrote:



My plan is to commit these changes to 11.0.x with the low risk parts 
(e.g. new methods) back-ported. Then, once we can see what is left, we 
can decide how quickly/slowly we want to back-port the complete fix to 
10.1.x and 9.0.x (the issue was reported against 10.1.x).


All is looking good so far.

The complete refactoring has been applied to 11.0.x

10.1.x and 9.0.x have the new header parser and are using it for the 
ChunkedInputFilter.


The question is how long do we want to wait before back-porting the 
standard HTTP header parsing? Essentially this means back-porting this 
commit:


https://github.com/apache/tomcat/commit/e5acf2cf0f745350c85d81532826d92b1882469a

Thoughts?

I'm thinking wait at least one release cycle before back-porting just in 
case of regressions given that this affects every request.


Mark

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

Refactoring heads up

[Mark Thomas]

Hi all,

The Spring folks have pinged me on an issue reported to them. The short 
version is that Tomcat doesn't support non-blocking reads of chunked 
request bodies.


While we have nearly all of the pieces we need to fix this, the commit 
is still going to be quite large involving quite a lot of changes to the 
ChunkedInputFilter. This will require some changes to Tomcat's internal 
API for ChunkedInputFilter - a number of protected fields and methods 
will be removed or made private.


I have this working locally except for trailer fields.

Closely related is the parsing of trailer fields. We already have a code 
comment saying this is very similar to HTTP fields (headers) but a 
common implementation isn't provided because fields use blocking or 
non-blocking IO but trailer fields only use blocking IO. Given we need 
to support non-blocking IO there is now a much stronger case for pulling 
the field (header) parsing code out to a separate class and reusing it 
for trailer fields.


I'm starting to work on this now and hope to complete the work this week.

Given these changes are going to impact pretty much every request I 
wanted to provide a heads up that these changes were on the way.


My plan is to commit these changes to 11.0.x with the low risk parts 
(e.g. new methods) back-ported. Then, once we can see what is left, we 
can decide how quickly/slowly we want to back-port the complete fix to 
10.1.x and 9.0.x (the issue was reported against 10.1.x).


Mark

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

Re: [VOTE] Release Apache Tomcat 10.1.23

[Mark Thomas]

On 23/04/2024 06:35, jean-frederic clere wrote:

On 4/17/24 12:00, Mark Thomas wrote:

Build is reproducible.


My tests here complain about examples, did I miss something.


No idea. You'd need to do a diff to see what didn't match and that will 
(hopefully) point you towards the root cause.


Mark



TCK tests are still running...




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

Re: Installation on Win 10 failure.

[Mark Thomas]

On 23/04/2024 03:31, DdC wrote:


I have installed tomcat originally with version 4.04 on winxp andlater on win7, 
ubuntu, and another linux box - many times by now.Trouble now with win10 and 
version 9.0.88.Yes, there is a jdk, CLASSPATH is set, j2ee.jar is in 
lib.Running in a cmd window with bin startup triggers another cmd windowto 
popup, shows errors flashing by and the 2nd window disappers.


Rather than running "startup.bat" use "catalina.bat run" which will keep 
the process in the same window and you'll be able to read any error message.


Alternatively, you could look in the logs directory. It is usually 
easiest if you empty the logs directory, attempt to start Tomcat and 
then check the log files for errors.


Mark




 Running subsequently shutdown gives: Tomcat may not be running.Thanks a lot ...
Each next window version made installation more difficult - or i gotolder :-)
Is win10 creating trouble? Or ?
Thanks for help ...

--
Home page:      rs6.risingnet.net/~ddccMarketing site:  www . OntoOO.comKindle 
books:   Side Effects: Impacts on the 21st 
Century::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09MHJ5W48   
Even if not 
true::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09Y4WR9J7   9/11:: 
They had the Sun in their 
Eyeshttps://www.amazon.com/11-They-had-their-Eyes-ebook/dp/B0CMQ2WSK9https://www.amazon.nl/dp/B0CMQ2WSK9





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

Re: (tomcat) branch main updated: Don't create a StringBuilder object until we know we have at least one Cookie value to log.

[Mark Thomas]

Ping. Just making sure this veto hasn't been lost in the recent flurry 
of commits.


Mark


On 18/04/2024 16:12, Mark Thomas wrote:

On 18/04/2024 14:31, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new 23facd507d Don't create a StringBuilder object until we know 
we have at least one Cookie value to log.

23facd507d is described below

commit 23facd507db72d583ed89a13f20ab1cb766f0221
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 09:30:50 2024 -0400

 Don't create a StringBuilder object until we know we have at 
least one Cookie value to log.


-1. veto. Please fix/revert ASAP.

Note: This veto applies to this commit and the back-ports.

This creates multiple paths where a NPE is possible.

This does not work if there are multiple cookies with the same name that 
need to be logged.


Mark



---
  java/org/apache/catalina/valves/AbstractAccessLogValve.java | 3 ++-
  webapps/docs/changelog.xml  | 4 
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git 
a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java

index 5502d1c183..e13bb9e5ac 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1479,7 +1479,7 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

  @Override
  public void addElement(CharArrayWriter buf, Date date, 
Request request, Response response, long time) {

-    StringBuilder value = new StringBuilder();
+    StringBuilder value = null;
  boolean first = true;
  Cookie[] cookies = request.getCookies();
  if (cookies != null) {
@@ -1490,6 +1490,7 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

  } else {
  value.append(',');
  }
+    value = new StringBuilder();
  value.append(cookie.getValue());
  }
  }
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 8ef77e52aa..f6c6c62962 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -123,6 +123,10 @@
  including the removal of the trimCredentials 
setting which

  is now hard-coded to false. (markt)
    
+  
+    Small performance optimization when logging cookies with no 
values.

+    (schultz)
+  
  
    
    


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



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



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

Re: (tomcat) 02/02: Re-factor ElapsedTimeElement to use a customizable Style

[Mark Thomas]

On 19/04/2024 13:31, Mark Thomas wrote:

On 19/04/2024 13:12, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit d3482c35bf144cc891dfa325b2f2f50460708c23
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 10:22:16 2024 -0400

 Re-factor ElapsedTimeElement to use a customizable Style


How is this customizable?

This seems to add complexity to somewhere we probably want to keep 
things simple.


Never mind. I think you meant extensible. I can see what you are trying 
to do in the PR that adds ns etc.


Mark




Mark



---
  .../catalina/valves/AbstractAccessLogValve.java    | 52 
+-

  webapps/docs/changelog.xml |  4 ++
  2 files changed, 44 insertions(+), 12 deletions(-)

diff --git 
a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java

index e13bb9e5ac..0576b83442 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1307,8 +1307,44 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

   * write time taken to process the request - %D, %T
   */
  protected static class ElapsedTimeElement implements 
AccessLogElement {

-    private final boolean micros;
-    private final boolean millis;
+    enum Style {
+    SECONDS {
+    @Override
+    public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));

+    }
+    },
+    MILLISECONDS {
+    @Override
+    public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));

+    }
+    },
+    MICROSECONDS {
+    @Override
+    public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));

+    }
+    };
+
+    /**
+ * Append the time to the buffer in the appropriate format.
+ *
+ * @param buf The buffer to append to.
+ * @param time The time to log in nanoseconds.
+ */
+    public abstract void append(CharArrayWriter buf, long time);
+    }
+    private final Style style;
+
+    /**
+ * Create a new ElapsedTimeElement that will log the time in 
the specified style.

+ *
+ * @param style The elapsed-time style to use.
+ */
+    public ElapsedTimeElement(Style style) {
+    this.style = style;
+    }
  /**
   * @param micros true, write time in 
microseconds - %D
@@ -1316,20 +1352,12 @@ public abstract class AbstractAccessLogValve 
extends ValveBase implements Access

   *   time in seconds - %T
   */
  public ElapsedTimeElement(boolean micros, boolean millis) {
-    this.micros = micros;
-    this.millis = millis;
+    this(micros ? Style.MICROSECONDS : millis ? 
Style.MILLISECONDS : Style.SECONDS);

  }
  @Override
  public void addElement(CharArrayWriter buf, Date date, 
Request request, Response response, long time) {

-    if (micros) {
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));

-    } else if (millis) {
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));

-    } else {
-    // second
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));

-    }
+    style.append(buf, time);
  }
  }
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index bda2e5d98c..f6eacba634 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -133,6 +133,10 @@
  dispatch is now performed rather than completing the request 
using the

  error page mechanism. (markt)
    
+  
+    Re-factor ElapsedTimeElement in AbstractAccessLogValve to use 
a customizable

+    style. (schultz)
+  
  
    
    


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



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



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

Re: (tomcat) 02/02: Re-factor ElapsedTimeElement to use a customizable Style

[Mark Thomas]

On 19/04/2024 13:12, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit d3482c35bf144cc891dfa325b2f2f50460708c23
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 10:22:16 2024 -0400

 Re-factor ElapsedTimeElement to use a customizable Style


How is this customizable?

This seems to add complexity to somewhere we probably want to keep 
things simple.


Mark



---
  .../catalina/valves/AbstractAccessLogValve.java| 52 +-
  webapps/docs/changelog.xml |  4 ++
  2 files changed, 44 insertions(+), 12 deletions(-)

diff --git a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
index e13bb9e5ac..0576b83442 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1307,8 +1307,44 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
   * write time taken to process the request - %D, %T
   */
  protected static class ElapsedTimeElement implements AccessLogElement {
-private final boolean micros;
-private final boolean millis;
+enum Style {
+SECONDS {
+@Override
+public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));
+}
+},
+MILLISECONDS {
+@Override
+public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));
+}
+},
+MICROSECONDS {
+@Override
+public void append(CharArrayWriter buf, long time) {
+
buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));
+}
+};
+
+/**
+ * Append the time to the buffer in the appropriate format.
+ *
+ * @param buf The buffer to append to.
+ * @param time The time to log in nanoseconds.
+ */
+public abstract void append(CharArrayWriter buf, long time);
+}
+private final Style style;
+
+/**
+ * Create a new ElapsedTimeElement that will log the time in the 
specified style.
+ *
+ * @param style The elapsed-time style to use.
+ */
+public ElapsedTimeElement(Style style) {
+this.style = style;
+}
  
  /**

   * @param micros true, write time in microseconds - %D
@@ -1316,20 +1352,12 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
   *   time in seconds - %T
   */
  public ElapsedTimeElement(boolean micros, boolean millis) {
-this.micros = micros;
-this.millis = millis;
+this(micros ? Style.MICROSECONDS : millis ? Style.MILLISECONDS : 
Style.SECONDS);
  }
  
  @Override

  public void addElement(CharArrayWriter buf, Date date, Request 
request, Response response, long time) {
-if (micros) {
-buf.append(Long.toString(TimeUnit.NANOSECONDS.toMicros(time)));
-} else if (millis) {
-buf.append(Long.toString(TimeUnit.NANOSECONDS.toMillis(time)));
-} else {
-// second
-
buf.append(Long.toString(TimeUnit.NANOSECONDS.toSeconds(time)));
-}
+style.append(buf, time);
  }
  }
  
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml

index bda2e5d98c..f6eacba634 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -133,6 +133,10 @@
  dispatch is now performed rather than completing the request using the
  error page mechanism. (markt)

+  
+Re-factor ElapsedTimeElement in AbstractAccessLogValve to use a 
customizable
+style. (schultz)
+  
  




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



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

Re: Tomcat closes connections on unexpected status codes

[Mark Thomas]

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

Hi Rémy, Mark,



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

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


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


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




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


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


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


Mark

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

Re: Tomcat closes connections on unexpected status codes

[Mark Thomas]

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

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


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



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


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


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


Mark





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


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


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

Hi,

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

10.1.19)

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

500,

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

induce

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

The 400 and 500 status codes are commonly used in RESTful

microservices to

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

for

closing connections on these status codes.

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

same

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


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


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

configurable.


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


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

Rémy


Mark




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

Kind regards,
Stefan Ansing

[1]:


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




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



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






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

Re: Tomcat closes connections on unexpected status codes

[Mark Thomas]

On 18/04/2024 14:41, Rémy Maucherat wrote:

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


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

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414, 500,
503, 501. This causes client applications to rapidly reconnect and induce
high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful microservices to
communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the same
behaviour, we believe that these status codes do not necessitate a new
connection.


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


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


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


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


I don't think it is quite that black and white.

If the client connects directly to the server (no proxy) then there 
request smuggling is a lot less likely and arguably impossible (assuming 
no Tomcat bugs).


If there is a proxy that is when there is a risk of request smuggling.

Given that there are circumstances where the risk of request smuggling 
is low (possibly none) it seems reasonable to allow users to configure 
the status codes that trigger connection close.


Mark

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

Re: (tomcat) branch main updated: Don't create a StringBuilder object until we know we have at least one Cookie value to log.

[Mark Thomas]

On 18/04/2024 14:31, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new 23facd507d Don't create a StringBuilder object until we know we have 
at least one Cookie value to log.
23facd507d is described below

commit 23facd507db72d583ed89a13f20ab1cb766f0221
Author: Christopher Schultz 
AuthorDate: Thu Apr 18 09:30:50 2024 -0400

 Don't create a StringBuilder object until we know we have at least one 
Cookie value to log.


-1. veto. Please fix/revert ASAP.

Note: This veto applies to this commit and the back-ports.

This creates multiple paths where a NPE is possible.

This does not work if there are multiple cookies with the same name that 
need to be logged.


Mark



---
  java/org/apache/catalina/valves/AbstractAccessLogValve.java | 3 ++-
  webapps/docs/changelog.xml  | 4 
  2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/catalina/valves/AbstractAccessLogValve.java 
b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
index 5502d1c183..e13bb9e5ac 100644
--- a/java/org/apache/catalina/valves/AbstractAccessLogValve.java
+++ b/java/org/apache/catalina/valves/AbstractAccessLogValve.java
@@ -1479,7 +1479,7 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
  
  @Override

  public void addElement(CharArrayWriter buf, Date date, Request 
request, Response response, long time) {
-StringBuilder value = new StringBuilder();
+StringBuilder value = null;
  boolean first = true;
  Cookie[] cookies = request.getCookies();
  if (cookies != null) {
@@ -1490,6 +1490,7 @@ public abstract class AbstractAccessLogValve extends 
ValveBase implements Access
  } else {
  value.append(',');
  }
+value = new StringBuilder();
  value.append(cookie.getValue());
  }
  }
diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 8ef77e52aa..f6c6c62962 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -123,6 +123,10 @@
  including the removal of the trimCredentials setting 
which
  is now hard-coded to false. (markt)

+  
+Small performance optimization when logging cookies with no values.
+(schultz)
+  
  




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



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

Re: Regarding Tomcat url redirection

[Mark Thomas]

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

Hi Team,

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


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


1. That isn't valid XML.

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



 
 
 
 



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

Mark

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

Re: Tomcat closes connections on unexpected status codes

[Mark Thomas]

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

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414, 500,
503, 501. This causes client applications to rapidly reconnect and induce
high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful microservices to
communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the same
behaviour, we believe that these status codes do not necessitate a new
connection.


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



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


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


Mark




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

Kind regards,
Stefan Ansing

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



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

Re: ASF on Redbubble

[Mark Thomas]

On 18/04/2024 06:54, Richard Zowalla wrote:

Hi all,

did we receive any updates/explanation?


No.


If the service is gone, we might want to update it's references in ASF sites.


Yes, it is gone. Any existing references need to be removed until we 
have replacement.


So far the only posdible alternative suggested is https://www.printful.com/

We could really do with a handful of alternatives to look at.

Mark




Gruß
Richard

Am 23. Februar 2024 09:11:39 MEZ schrieb Mark Thomas :

All,

It isn't looking good. Redbubble have denied the suspension appeal and still 
haven't explained why the account has been suspended. I've asked but I am not 
sure I am going to get a response.

I think we need to start looking for alternative services.

Suggestions welcome.

I haven't informed the PMCs using Redbubble yet. I'll do that if my request for 
an explanation of why the account was suspended gets nowhere.

Mark


On 21/02/2024 15:31, Mark Thomas wrote:

On 21/02/2024 14:44, Richard Zowalla wrote:

Hey Mark,
I am unable to find the ComDev store  on Redbubble at all.
My previous orders from ComDev are gone (or I ordered from the wrong
people in the recent years).

So if you have a link for me, would be great :)


Sigh. Redbubble have suspended our account. I'll see what I can do to fix that.

Mark



Best
Richard



Am Mittwoch, dem 21.02.2024 um 08:46 + schrieb Mark Thomas:

On 20/02/2024 21:55, Jeff Zemerick wrote:

Hi all,

Hopefully this list is the best place for this.

I have ordered several OpenNLP shirts in the past from Redbubble. I
did a
recent order for OpenNLP, Airflow, Solr, and NiFi shirts (can never
have
enough, right?) and RedBubble canceled the OpenNLP and Airflow ones
due to
Redbubble’s IP/Publicity Rights Policy [1].


I only see Solr in the ComDev store. It may be the case that
RedBubble
is (finally) taking steps against sellers that sell items using logos
they don't have the rights to. Last time I went looking there were a
LOT
of items with logos for commercial software. You might have got
caught
up in that.


I just wanted to bring it to the ASF's attention. Is Redbubble
still the
place to get ASF swag?


It is the place ComDev maintains although some projects may have set
up
alternatives.

The simplest solution may be to get those PMCs to request that the
relevant logos are added to the ComDev store. It just needs an email
from someone on the PMC to this list confirming that the PMC would
like
the logo added.

Mark

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




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



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



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





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

Re: [VOTE] Release Apache Tomcat 10.1.23

[Mark Thomas]

On 16/04/2024 14:11, Christopher Schultz wrote:

The proposed 10.1.23 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.1.23


Unit tests pass on Linux, Windows and MacOS (M1).

Build is reproducible.

Mark

PS I am still unable to test on MacOS (Intel) as it is a $dayjob 
provided laptop and the mandatory AV software is slowing the tests down 
to the point that lots of them fail.


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

Re: Tomcat log warnings for connection parameter limits?

[Mark Thomas]

It would be worth creating an enhancement request for this in Bugzilla 
to ensure the request doesn't get forgotten about.


Mark


On 16/04/2024 01:06, Baron Fujimoto wrote:

 From our perspective, it needn't be super timely. It would be more for
forensic confirmation that there's something we should consider. I think a
hysteresis behavior would be compatible with this.

On Mon, Apr 15, 2024 at 12:00 AM Mark Thomas  wrote:


On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be
something that would be left on in a live> system. We can set these
parameters, so it would be useful to know if we

were hitting the set limits.


For the connection limit:

How timely do you need the information to be? It is much easier to add a
check when the connection is closed since a) it returns the current
count and b) we are already checking the return value for mis-counting.

For the thread limit:

We have a couple of options here. (We use a custom queue which
effectively changes the way threads in the pool re used.) The simplest
is probably to add log in TaskQueue.offer() if all threads are currently
being used.


I'm not sure I fully grasp how this additional logging presents a
significant incremental DOS risk. I mean, if an attacker is flooding you
with enough traffic or connections where this becomes an issue, aren't

you

already logging various aspects of the attempts anyway (e.g., access

logs,

etc)? At that point aren't your logs already being filled anyway?


It is an area we need to be careful with. Log messages that include
exceptions are of greatest concern since they are relatively expensive
to generate. If an invalid HTTP message triggers a log message with an
exception (it does, but only when configured for debug logging) then
there is a degree of DoS risk there.

Access logs are a special case and one that we have taken care to try
and optimise. Still, if you want to make a performance test look good
turning off access logging is one of the first things to do (and of
course results in totally meaningless results that don't reflect real
world usage).

I think the concern Chris was trying to express (although I'm sure he'll
correct me if I am wrong) is that when these limits are reached there is
a risk of a lot of log messages being generated and that can cause
issues both from a performance issue and from just filling the logs with
the same message over and over again.

I think what we would need is some form of hysteresis. Log a message
when the limit is reached, log another message when usage falls below
80%? of the limit. That way, administrators see the peaks in usage but
aren't inundated with log messages.

My only concern is that at least some this code is going to run for
every single request. It needs to be efficient. We should measure the
impact of adding this code before we decide on whether to include it.

Mark




On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Baron,

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

I'm investigating occasional 503 errors for our CAS service running in

a

Tomcat 10.1.x container. The 503s appear to correlate with some traffic
spikes at the same time.

The connector is configured as follows:

   

Can Tomcat log info such as when the maxThreads or maxConnections

limits

are reached? I'm basically trying to see if there is a good way to
more definitively determine what may have caused the 503s and what may

be

feasible to mitigate them.


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

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

-chris

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






-
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: jakartaee/servlet pom.xml

[Mark Thomas]

On 16/04/2024 08:23, xulin y wrote:

Hi,

I refer to this commit:
https://github.com/jakartaee/servlet/commit/1455686360e118a68a545fb2e1b74f1c79abcfb5


And I ask again. How is that a Tomcat issue?

Mark




By Xulin Yang
Kind Regards

Mark Thomas  于2024年4月16日周二 15:20写道：


The list drops images. What changed?

Mark


On 16/04/2024 07:52, xulin y wrote:

Hi,

image.png
You can see this version was changed from 6.1.0-M2 to 6.1.0 on 2024 Mar
27 while 6.1.0 is not present in


https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/


image.png

By Xulin Yang
Kind Regards

Mark Thomas mailto:ma...@apache.org>> 于2024年4月16日
周二 14:48写道：

 How is this an Apache Tomcat issue?

 Mark


 On 16/04/2024 07:41, xulin y wrote:
  > Hi,
  >
  > System OS: Windows 10
  > Maven: 3.9.6
  > Java: 17.0.1
  >
  > When I was "mvn install" jakartaee/servlet on my desktop. I found
  >


https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37
<
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37>
<
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37
<
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37>>
can give me exception. This is because
https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>>
does not have jakarta.servlet-api 6.1.0

  > image.png
  > I use 6.1.0-SNAPSHOT on my desktop instead. Could you take a look
 at this?
  >
  > Appendix:
  > [ERROR] Failed to execute goal on project tck-runtime: Could not
 resolve
  > dependencies for project
 jakarta.servlet:tck-runtime:jar:6.1.0-SNAPSHOT:
  > The following artifacts could not be resolved:
  > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 (absent):
  > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 was not found
  >
  > By Xulin Yang
  > Kind Regards

 -
 To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
 <mailto:dev-unsubscr...@tomcat.apache.org>
 For additional commands, e-mail: dev-h...@tomcat.apache.org
 <mailto:dev-h...@tomcat.apache.org>



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






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

Re: Base64 and BASIC authentication

[Mark Thomas]

On 16/04/2024 08:18, Mark Thomas wrote:



Tomcat's current implementation is based on RFC 2617 and allows the 
following:

- white space around the base64
- allows embedded line breaks in the base64
- missing padding
- illegal characters in the base64 (ignored)
- illegal characters in the base64 padding (ignored)
- excessive padding
- whitespace around the decoded password

I don't see any of the above causing issues apart from the last one 
which prevents the use of passwords with leading or trailing whitespace.


Just following up on this.

Prior to Tomcat 9.0.15, Tomcat always did this.

From 9.0.15 Tomcat did this by default but it could be disabled.

Intend to remove this feature from Tomcat 11 and disable it by default 
in earlier versions.


Mark

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

Re: jakartaee/servlet pom.xml

[Mark Thomas]

The list drops images. What changed?

Mark


On 16/04/2024 07:52, xulin y wrote:

Hi,

image.png
You can see this version was changed from 6.1.0-M2 to 6.1.0 on 2024 Mar 
27 while 6.1.0 is not present in 
https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/ <https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>

image.png

By Xulin Yang
Kind Regards

Mark Thomas mailto:ma...@apache.org>> 于2024年4月16日 
周二 14:48写道：


How is this an Apache Tomcat issue?

Mark


On 16/04/2024 07:41, xulin y wrote:
 > Hi,
 >
 > System OS: Windows 10
 > Maven: 3.9.6
 > Java: 17.0.1
 >
 > When I was "mvn install" jakartaee/servlet on my desktop. I found
 >
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37 
<https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37> 
<https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37 
<https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37>> can give me exception. 
This is because https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/ 
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/> 
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/ 
<https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/>> does not have 
jakarta.servlet-api 6.1.0
 > image.png
 > I use 6.1.0-SNAPSHOT on my desktop instead. Could you take a look
at this?
 >
 > Appendix:
 > [ERROR] Failed to execute goal on project tck-runtime: Could not
resolve
 > dependencies for project
jakarta.servlet:tck-runtime:jar:6.1.0-SNAPSHOT:
 > The following artifacts could not be resolved:
 > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 (absent):
 > jakarta.servlet:jakarta.servlet-api:jar:6.1.0 was not found
 >
 > By Xulin Yang
 > Kind Regards

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
<mailto:dev-unsubscr...@tomcat.apache.org>
For additional commands, e-mail: dev-h...@tomcat.apache.org
<mailto:dev-h...@tomcat.apache.org>



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

Base64 and BASIC authentication

[Mark Thomas]

Hi all,

TL;DR - we need to tighten up parsing of BASIC authentication headers.

When I switched out Tomcat's Base64 handling for the built-in JRE 
handling, I noticed that BASIC authentication was using a very relaxed 
version of the Base64 decoder. That seemed odd, so I replaced it with 
the standard Base64 decoder. That broke a bunch of tests so I switched 
to the MIME decoder (the most relaxed) which fixed most - but not all - 
of the issues. Then I started look at what the tests were testing and 
the relevant RFCs.


The current RFC for HTTP BASIC authentication is RFC 7617. This in turn 
references numerous other RFCs, most notably RFC 7235 (HTTP 
Authentication) and RFC 4648 (Base64). Taken together these require that 
the format of the Authorization header is:

- The token "Basic"
- Exactly 1 space
- The base64 encoding of username:password

Tomcat's current implementation is based on RFC 2617 and allows the 
following:

- white space around the base64
- allows embedded line breaks in the base64
- missing padding
- illegal characters in the base64 (ignored)
- illegal characters in the base64 padding (ignored)
- excessive padding
- whitespace around the decoded password

I don't see any of the above causing issues apart from the last one 
which prevents the use of passwords with leading or trailing whitespace. 
This is mostly of a cleaning up exercise so the switch to Java's base64 
decoder is simpler.


Before I merge the change to use the JRE's Base64 encoder, I intend to 
tighten up the parsing of Basic authentication headers. I intend to do 
this for all currently supported versions.


Any objections?

Mark

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

Re: jakartaee/servlet pom.xml

[Mark Thomas]

How is this an Apache Tomcat issue?

Mark


On 16/04/2024 07:41, xulin y wrote:

Hi,

System OS: Windows 10
Maven: 3.9.6
Java: 17.0.1

When I was "mvn install" jakartaee/servlet on my desktop. I found 
https://github.com/jakartaee/servlet/blob/master/tck/tck-runtime/pom.xml#L37  can give me exception. This is because https://repo.maven.apache.org/maven2/jakarta/servlet/jakarta.servlet-api/  does not have jakarta.servlet-api 6.1.0

image.png
I use 6.1.0-SNAPSHOT on my desktop instead. Could you take a look at this?

Appendix:
[ERROR] Failed to execute goal on project tck-runtime: Could not resolve 
dependencies for project jakarta.servlet:tck-runtime:jar:6.1.0-SNAPSHOT: 
The following artifacts could not be resolved: 
jakarta.servlet:jakarta.servlet-api:jar:6.1.0 (absent): 
jakarta.servlet:jakarta.servlet-api:jar:6.1.0 was not found


By Xulin Yang
Kind Regards


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

Re: (tomcat) 01/06: Remove unused code - thanks to UCDetector

[Mark Thomas]

On 05/04/2024 12:55, Mark Thomas wrote:

5 Apr 2024 04:33:42 Christopher Schultz :


Mark,

Can't this entire class be replaced with calls to 
java.util.Base64.get*Encoder and java.util.Base64.get*Decoder wherever 
necessary?


Now that 9.0.x is oldest, we should be able to use java.util.Base64 
from Java 1.8+


Possibly. There is a commit from 2.0.x that does that that we could back 
port.


The one thing I wanted to check was that the Tomcat one was stricter for 
URL safe Vs non URL safe. I wasn't sure how that applied here.


My main concern was aligning 9.0.x through 11.0.x which is now done. 
Improvements like this were next on the TODO list for File upload.


I've done more checks and it was the commons implementation that used 
the same decoder for standard and URL-safe. The Java implementation has 
specific decoders for each.


It looks like we can remove the o.a.tomcat.util.codec.binary package 
completely. I'll take a look. If it is possible then the plan would be 
remove in 11.0.x and deprecate in 10.1.x and earlier just in case 
someone is using the Tomcat internals directly.


Mark

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

Re: Package URLs for Apache Tomcat distributions

[Mark Thomas]

On 11/04/2024 16:52, von Loewenstein, Jan wrote:

Hi folks,

I am part of the Paketo community, and we are providing Cloud Native Buildpacks 
to create container images with – amongst other technologies – Apache Tomcat 
and Apache TomEE as application runtimes.

One of the features of Cloud Native Buildpacks is that images come with 
Software-Bill-of-Material. When installing Apache Tomcat, we issue the 
following CPE and pURL to the SBOM:

   1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
   2.  pkg:generic/apache-tomcat@10.1.20

The former should be the right one for users to find relevant CVEs in e.g. the 
nvd.nist.gov. The latter however is made up and will likely not lead to any 
findings on e.g. https://osv.dev

Now I am wondering if you report Tomcat vulnerabilities under any pURL and 
which one that would be.


We don't.


There is a 
proposal
 to introduce `pkg:apache` as a namespace, which would open up 
`pkg:apache/tomcat@10.1.20` as a canonical pURL.


That is a foundation wide decision and not one the Tomcat project can 
make unilaterally. That is probably a topic for 
security-disc...@community.apache.org where pURL has already been 
touched on this thread:

https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv

Mark

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

Re: Tomcat log warnings for connection parameter limits?

[Mark Thomas]

On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be 
something that would be left on in a live> system. We can set these 
parameters, so it would be useful to know if we

were hitting the set limits.


For the connection limit:

How timely do you need the information to be? It is much easier to add a 
check when the connection is closed since a) it returns the current 
count and b) we are already checking the return value for mis-counting.


For the thread limit:

We have a couple of options here. (We use a custom queue which 
effectively changes the way threads in the pool re used.) The simplest 
is probably to add log in TaskQueue.offer() if all threads are currently 
being used.



I'm not sure I fully grasp how this additional logging presents a
significant incremental DOS risk. I mean, if an attacker is flooding you
with enough traffic or connections where this becomes an issue, aren't you
already logging various aspects of the attempts anyway (e.g., access logs,
etc)? At that point aren't your logs already being filled anyway?


It is an area we need to be careful with. Log messages that include 
exceptions are of greatest concern since they are relatively expensive 
to generate. If an invalid HTTP message triggers a log message with an 
exception (it does, but only when configured for debug logging) then 
there is a degree of DoS risk there.


Access logs are a special case and one that we have taken care to try 
and optimise. Still, if you want to make a performance test look good 
turning off access logging is one of the first things to do (and of 
course results in totally meaningless results that don't reflect real 
world usage).


I think the concern Chris was trying to express (although I'm sure he'll 
correct me if I am wrong) is that when these limits are reached there is 
a risk of a lot of log messages being generated and that can cause 
issues both from a performance issue and from just filling the logs with 
the same message over and over again.


I think what we would need is some form of hysteresis. Log a message 
when the limit is reached, log another message when usage falls below 
80%? of the limit. That way, administrators see the peaks in usage but 
aren't inundated with log messages.


My only concern is that at least some this code is going to run for 
every single request. It needs to be efficient. We should measure the 
impact of adding this code before we decide on whether to include it.


Mark




On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Baron,

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

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

The connector is configured as follows:

  

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


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

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

-chris

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






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

Re: Retrieve server.built, server.number

[Mark Thomas]

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

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


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

application. Be Careful.


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

:)

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



The amusing thing (or irritating thing, depending on your point of view) is
when a large organization uses a vulnerability scanner and a Tomcat
instance gets flagged as a security risk because it reveals its version
number in the 404 error page. (Yes, this is a real scenario.)


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

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


Mark

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

Re: Retrieve server.built, server.number

[Mark Thomas]

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

All,

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

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

Hi All,

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


In a default installation, no.

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


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


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


:)

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


Mark

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

Re: Retrieve server.built, server.number

[Mark Thomas]

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

Hi All,

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


In a default installation, no.

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


Mark




I am currently running tomcat v 9.0.87.

This information gets displayed when we run version.sh or in the starting
logs when tomcat starts up but how we can find it without logging into the
tomcat server.

Thanks,



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

Re: Tomcat & Http 103 Early Hint

[Mark Thomas]

Contributions always welconme.

The initial work will be on the changes to the Servlet API. The issue to 
track that is:

https://github.com/jakartaee/servlet/issues/542

Mark


On 09/04/2024 08:15, xulin y wrote:

Hi Mark,

Is there any chance I could help with delivering this new feature? At
least, I can help with writing some tests.

I think this new http feature can be beneficial a lot for web application
page load performance. Therefore, this is crucial for the whole Tomcat
community.

By Xulin Yang
Kind Regards

Mark Thomas  于2024年4月8日周一 19:24写道：


8 Apr 2024 10:26:23 xulin y :


Hi,
I would like to ask about whether Tomcat has support for http 103 early
hint response status?


Not at the moment.


I have checked the latest
doc that



https://tomcat.apache.org/tomcat-11.0-doc/servletapi/jakarta/servlet/http/HttpServletResponse.html

does not have 103 response status.

If not, do we have any plan to implement it?


It is expected to be part of Servlet.next / Tomcat 12. If possible, there
is a good chance it will be back-ported to earlier Tomcat versions.

Mark




By Xulin Yang
Kind Regards


-
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 & Http 103 Early Hint

[Mark Thomas]

8 Apr 2024 10:26:23 xulin y :


Hi,
I would like to ask about whether Tomcat has support for http 103 early
hint response status?


Not at the moment.


I have checked the latest
doc that

https://tomcat.apache.org/tomcat-11.0-doc/servletapi/jakarta/servlet/http/HttpServletResponse.html
does not have 103 response status.

If not, do we have any plan to implement it?


It is expected to be part of Servlet.next / Tomcat 12. If possible, there 
is a good chance it will be back-ported to earlier Tomcat versions.


Mark




By Xulin Yang
Kind Regards


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

Re: Intermittent error 404

[Mark Thomas]

8 Apr 2024 11:20:09 andreas.moro...@wobi.bz.it:


Hello
we use Apache Tomcat/8.5.99.


Tomcat 8.5.x is no longer supported by the Tomcat community. You should 
upgrade to at least 9.0.x or consider purchasing 8.5.x support from one 
of the commercial vendors that offer it.


It sounds like an issue with JSP compilation. I'd suggest stopping 
Tomcat, cleaning out the work directory and then starting Tomcat.


Mark



Last week I changed the user of the Tomcat services.


When I refresh teh page then every second time the page appears 
correctly and the other 50% I get the error


No I get intermittent error 404

The origin server did not find a current representation for the target 
resource or is not willing to disclose that one exists.


on the index.jsp

The user has the rights to read the index.jsp

The fact that sometimes it works and the next time it doesn't confuses 
me. If it were due to the rights, it should probably never work.

Can someone kindly help me?

Greetings
Andreas

Institut für den sozialen Wohnbau des Landes Südtirol
Istituto per l’edilizia sociale della Provincia autonoma di Bolzano
39100 Bozen Horazstraße 14 / 39100 Bolzano via Orazio, 14_*
*__*wobi.bz.it[https://www.wobi.bz.it/de/default.asp]*_*   
*_*ipes.bz.it[https://www.ipes.bz.it/it/default.asp]*_*



*[cid:_4_00C1B7780DBA0634003348A4C1258AF9]*

*
Dies ist eine vertrauliche Nachricht und nur für den Adressaten 
bestimmt. Sollten Sie diese Nachricht irrtümlich erhalten haben, bitten 
wir um Ihre diesbezügliche Benachrichtigung und um die Löschung der 
Nachricht. Eine Veröffentlichung oder Verbreitung des Inhaltes sowie 
jegliche anderweitige Verwendung sind untersagt.


Il contenuto di questa e-mail è rivolto esclusivamente al destinatario 
della stessa e deve intendersi riservato e personale. Laddove questa 
e-mail Le fosse pervenuta per errore, Le chiediamo di comunicarci 
l’errata notifica e di cancellarne il contenuto. Sono sempre vietate la 
pubblicazione o diffusione del contenuto, nonché l'utilizzo per 
qualsiasi altro scopo.


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

Re: April releases

[Mark Thomas]

On 07/04/2024 17:44, Rémy Maucherat wrote:

On Sat, Apr 6, 2024 at 2:21 PM Mark Thomas  wrote:


5 Apr 2024 14:18:49 Rémy Maucherat :


On Fri, Apr 5, 2024 at 2:02 PM Mark Thomas  wrote:


Hi all,

Just a heads up that I have a lot on my plate at the moment and the
April
tag for 11.0.x is unlikely to happen for a couple of weeks.

There are changes I'd like to see in a release but I don't think there
is
anything urgent.


I can help by doing the 11 M release. I would probably skip the
localization update for this round though.


That would be great if you could.

I'm hoping to get some Commons FileUpload changes finished over the
weekend if you can wait until Monday.


I cannot do anything on weekends these days.


Ack.


I figured out how the import/export from poeditor worked, but I'm a
bit worried about clicking import on the website. I would import the
properties with the full US strings, but without "Overwrite existing
translations" ?


You want to overwrite the translations to pick up any updates to the 
English versions.



So most likely I'll only import the languages with some updates and that's it.


That would be great.

Mark

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

Re: April releases

[Mark Thomas]

5 Apr 2024 14:18:49 Rémy Maucherat :


On Fri, Apr 5, 2024 at 2:02 PM Mark Thomas  wrote:


Hi all,

Just a heads up that I have a lot on my plate at the moment and the 
April

tag for 11.0.x is unlikely to happen for a couple of weeks.

There are changes I'd like to see in a release but I don't think there 
is

anything urgent.


I can help by doing the 11 M release. I would probably skip the
localization update for this round though.


That would be great if you could.

I'm hoping to get some Commons FileUpload changes finished over the 
weekend if you can wait until Monday.


Mark




Rémy

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


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

April releases

[Mark Thomas]

Hi all,

Just a heads up that I have a lot on my plate at the moment and the April 
tag for 11.0.x is unlikely to happen for a couple of weeks.


There are changes I'd like to see in a release but I don't think there is 
anything urgent.


Mark

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

Re: (tomcat) 01/06: Remove unused code - thanks to UCDetector

[Mark Thomas]

5 Apr 2024 04:33:42 Christopher Schultz :


Mark,

Can't this entire class be replaced with calls to 
java.util.Base64.get*Encoder and java.util.Base64.get*Decoder wherever 
necessary?


Now that 9.0.x is oldest, we should be able to use java.util.Base64 
from Java 1.8+


Possibly. There is a commit from 2.0.x that does that that we could back 
port.


The one thing I wanted to check was that the Tomcat one was stricter for 
URL safe Vs non URL safe. I wasn't sure how that applied here.


My main concern was aligning 9.0.x through 11.0.x which is now done. 
Improvements like this were next on the TODO list for File upload.


Mark




?

-chris

On 4/4/24 15:52, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.
markt pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 1a2f722e405ec17c5dab5fac43ae2fe63eb8fbce
Author: Mark Thomas 
AuthorDate: Fri Jun 17 12:29:10 2022 +0100
 Remove unused code - thanks to UCDetector
---
  .../apache/tomcat/util/codec/binary/Base64.java    | 155 
-
  .../tomcat/util/codec/binary/BaseNCodec.java   |  88 


  2 files changed, 243 deletions(-)
diff --git a/java/org/apache/tomcat/util/codec/binary/Base64.java 
b/java/org/apache/tomcat/util/codec/binary/Base64.java

index a733df9937..e38bf3df17 100644
--- a/java/org/apache/tomcat/util/codec/binary/Base64.java
+++ b/java/org/apache/tomcat/util/codec/binary/Base64.java
@@ -16,9 +16,6 @@
   */
  package org.apache.tomcat.util.codec.binary;
  -import java.math.BigInteger;
-import java.util.Objects;
-
  /**
   * Provides Base64 encoding and decoding as defined by href="http://www.ietf.org/rfc/rfc2045.txt;>RFC 2045.

   *
@@ -141,20 +138,6 @@ public class Base64 extends BaseNCodec {
  // The private member fields below are used with the new 
streaming approach, which requires
  // some state be preserved between calls of encode() and 
decode().

  -    /**
- * Decodes Base64 data into octets.
- * 
- * Note: this method seamlessly handles data encoded in 
URL-safe or normal mode.

- * 
- *
- * @param base64Data
- *    Byte array containing Base64 data
- * @return Array containing decoded data.
- */
-    public static byte[] decodeBase64(final byte[] base64Data) {
-    return decodeBase64(base64Data, 0, base64Data.length);
-    }
-
  public  static byte[] decodeBase64(
  final byte[] base64Data, final int off, final int len) {
  return new Base64().decode(base64Data, off, len);
@@ -180,29 +163,6 @@ public class Base64 extends BaseNCodec {
  }
    // Implementation of integer encoding used for crypto
-    /**
- * Decodes a byte64-encoded integer according to crypto standards 
such as W3C's XML-Signature.

- *
- * @param pArray
- *    a byte array containing base64 character data
- * @return A BigInteger
- * @since 1.4
- */
-    public static BigInteger decodeInteger(final byte[] pArray) {
-    return new BigInteger(1, decodeBase64(pArray));
-    }
-
-    /**
- * Encodes binary data using the base64 algorithm but does not 
chunk the output.

- *
- * @param binaryData
- *    binary data to encode
- * @return byte[] containing Base64 characters in their UTF-8 
representation.

- */
-    public static byte[] encodeBase64(final byte[] binaryData) {
-    return encodeBase64(binaryData, false);
-    }
-
  /**
   * Encodes binary data using the base64 algorithm, optionally 
chunking the output into 76 character blocks.

   *
@@ -272,17 +232,6 @@ public class Base64 extends BaseNCodec {
  return b64.encode(binaryData);
  }
  -    /**
- * Encodes binary data using the base64 algorithm and chunks the 
encoded output into 76 character blocks

- *
- * @param binaryData
- *    binary data to encode
- * @return Base64 characters chunked in 76 character blocks
- */
-    public static byte[] encodeBase64Chunked(final byte[] binaryData) 
{

-    return encodeBase64(binaryData, true);
-    }
-
  /**
   * Encodes binary data using the base64 algorithm but does not 
chunk the output.

   *
@@ -298,19 +247,6 @@ public class Base64 extends BaseNCodec {
  return StringUtils.newStringUsAscii(encodeBase64(binaryData, 
false));

  }
  -    /**
- * Encodes binary data using a URL-safe variation of the base64 
algorithm but does not chunk the output. The
- * url-safe variation emits - and _ instead of + and / 
characters.

- * Note: no padding is added.
- * @param binaryData
- *    binary data to encode
- * @return byte[] containing Base64 characters in their UTF-8 
representation.

- * @since 1.4
- */
-    public static byte[] encodeBase64URLSafe(final byte[] binaryData) 
{

-    return encodeBase64(binaryData, fal

Re: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element

[Mark Thomas]

On 02/04/2024 15:41, Rick Noel wrote:

Mark you were correct. I, needed to move those attributes to the Connection 
element.
Plus on top of that I had this misspelled attribute  compressableMinemType
should be compressibleMimeType

In your opinion, should we use the Upgrade UpgradeProtcol protocol?


It depends. h2 is more performant in some circumstances. Best to test 
and find out.



I mean does not the semantics of its name imply it is better?


I'm afraid not. It is just the name of the process (HTTP upgrade) use to 
transition from HTTP/1.1 to h2c.


Mark




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

-Original Message-
From: Mark Thomas 
Sent: Tuesday, April 2, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: unable to set compression, compressionMinSize and 
compressableMinemType attributes in UpgradeProtocol element

On 02/04/2024 14:53, Rick Noel wrote:

Hello,

What am I missing here?


You haven't provided information on the Tomcat version you are using.
I'm assuming 10.1.x.

https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html

Search for compressionMinSize.


I get warnings that the compression related attributes of compression, 
compressionMinSize and compressableMinemType are not being set.





I have also tried moving of compression, compressionMinSize and
compressableMinemType to the Connector element with same results


That seems ... unlikely. Please provide the Connector configuration and the 
error message.


BTW, I am supposed to get improved speed by using the  UpgradeProtcol  
Correct?


It depends. YMMV.

Mark

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

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


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



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

Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element

[Mark Thomas]

On 02/04/2024 14:53, Rick Noel wrote:

Hello,

What am I missing here?


You haven't provided information on the Tomcat version you are using. 
I'm assuming 10.1.x.


https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html

Search for compressionMinSize.


I get warnings that the compression related attributes of compression, 
compressionMinSize and compressableMinemType are not being set.





I have also tried moving of compression, compressionMinSize and 
compressableMinemType to the Connector element with same results


That seems ... unlikely. Please provide the Connector configuration and 
the error message.



BTW, I am supposed to get improved speed by using the  UpgradeProtcol  
Correct?


It depends. YMMV.

Mark

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

Re: [DISCUSS] Should we update our policies to include source provenance check

[Mark Thomas]

On 02/04/2024 09:12, sebb wrote:

On Tue, 2 Apr 2024 at 08:47, Christofer Dutz  wrote:


Hi all,



I fully agree on this … and adding to sebb’s statement that additional files 
can happen even without malicious intent.

I have seen this several times, if for example maven releases are built 
directly from the main checkout and not from the release-plugin checking out 
the release commit hash and building in a clean directory.



A clean checkout helps, but is no guarantee.

Spurious files can end up in a source tarball even when it is created
from a clean checkout.

I saw this in a Maven build where faulty test code left behind some
test artifacts.
Since Maven creates the source archive after the test phase, such
files can end up being included.


Nice idea in principle, but it is going to create issues for C based 
projects in practice.


End users expect to be able to build C based projects with configure, 
make, make install. That only works because the release manager runs a 
script (typically called buildconf that uses autoconf) to create the 
support scripts required in the src tarball.


There are various possible solutions but I strongly suggest engagement 
with projects such as httpd before trying to change the current policy.


Mark

-
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org

Re: PKCS#8 encryption algorithm unrecognized

[Mark Thomas]

4M3.mydomain.com.key" -out "C:\tmp12\Certificate\Private
Key\WSD-2DNX4M3.mydomain.com.key.2" -passin pass:"changeit"
openssl.exe rsa -aes256 -in "C:\tmp12\Certificate\Private
Key\WSD-2DNX4M3.mydomain.com.key.2" -out "C:\tmp12\Certificate\Private
Key\WSD-2DNX4M3.mydomain.com.key.3" -passin pass:"changeit" -passout
pass:"changeit"
openssl.exe pkcs8 -topk8 -v1 PBE-SHA1-3DES -in
"C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key.3" -out
"C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key" -passin
pass:"changeit" -passout pass:"changeit"

DEL /Q "C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key.2"
DEL /Q "C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key.3"

keytool.exe -importkeystore -srckeystore
"C:\tmp12\Certificate\Keystore\Vessel.jks" -destkeystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -srcstoretype JKS -deststoretype
PKCS12 -srcstorepass "changeit" -deststorepass "changeit" -noprompt
keytool.exe -delete -alias "ASA12 SAMM Vessel Temporary CA" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt
keytool.exe -delete -alias "ASA12 SAMM Vessel" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt
keytool.exe -delete -alias "WSD-2DNX4M3.mydomain.com" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt
keytool.exe -import -alias "ASA12 SAMM Vessel" -file "C:\tmp12\Client
Configuration.pem" -keystore "C:\tmp12\Certificate\Keystore\Vessel.p12"
-storepass "changeit" -noprompt
keytool.exe -import -trustcacerts -alias "ASA12 SAMM Vessel Temporary CA"
-file "C:\tmp12\Client Configuration.pem" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt


if you need anything else please get in touch with me.
I have tested this with the Tomcat 87 release and it still does not work.

Thanks

Mark Resh




On Tue, Mar 19, 2024 at 4:15 PM Mark Thomas  wrote:


On 19/03/2024 18:18, Timothy Resh wrote:


ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"


  SSLPassword="${KSENC(6qkaMErQ==;

C:\Certificate\Keystore\Vessel.p12)}"

SSLCertificateChainFile="C:Certificate\Public Key\WSD-2DNX4M3...cer"
SSLCertificateFile="C:\Certificate\Public Key\WSD-2DNX4M3...cer"
SSLCertificateKeyFile="C:\Certificate\Private Key\WSD-2DNX4M3..key"
SSLVerifyClient="optional"
SSLCACertificateFile="C:\Certificates\CA\intermediate.ca"
SSLCACertificatePath="C:\Certificates\CA\"




where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below. I have read some of the
https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask

for

help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?


Please provide a set of OpenSSL commands that create a problematic,
self-signed certificate for localhost. This will save us a *lot* of time.

Mark




Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at

org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at


org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at


org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:103

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

[Mark Thomas]

On 29/03/2024 21:58, Christopher Schultz wrote:

Rick,

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

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

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

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


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


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


The only reason you might want to touch context.xml is if you want to 
provide the same resource link to all web applications rather than have 
to specify it in each web application.


Mark



-chris


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

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


Rick,

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

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


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

It also makes upgrades more difficult.

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


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


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


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

    
  jdbc/foo
  javax.sql.DataSource
  Container
    

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


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


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


Doing all this will make upgrading Tomcat much easier.

-chris


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

Rick,

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

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

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


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

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

I have xxx out postgres URL for security reasons





     
type="javax.sql.DataSource"  driverClassName="org.postgresql.Driver"
 
url="jdbc:postgresql://xxx"
 username="postgres" 
password="postgres4now"
 maxTotal="30"  maxIdle="30" 
maxWaitMillis="-1"
 
removeAbandonedOnBorrow="true" removeAbandonedTimeout="90"
 testOnBorrow="true"  
validationQuery="select 1" validationQueryTimeout="3"
 testWhileIdle="true"  
timeBetweenEvictionRunsMillis="6"

 testOnReturn="true"
  />


 



Below is my database resource   as defined in context.xml




   



      type="javax.sql.DataSource"  
driverClassName="org.postgresql.Driver"

    url="jdbc:postgresql://xx
    username="postgres" password="postgres4now"
    maxTotal="30"  maxIdle="30" maxWaitMillis="-1"
    removeAbandonedOnBorrow="true" 

Re: Stop releasing Tomcat 9 or adding back Tomcat 10.0?

[Mark Thomas]

On 27/03/2024 08:48, Romain Manni-Bucau wrote:

Hi all,

Checkout out TomEE's notifications I realized Tomcat is in a weirdish
situation where Tomcat 9 is Servlet 4 and "+1" version is Tomcat 10.1 which
is Servlet 6.
It means Tomcat is no more a Servlet 5 friendly option.

I wonder if it means Tomcat < 10.1 should be stopped too or if Tomcat 10.0
should be maintained and released again - pretty sure we can find help if
desired for that not that far.
Another option is to restore the deleted methods between servlet 5-6 in the
code base to be able to run Tomcat 10.1 with Servlet 5 API instead of
Servlet 6 - to pass signature TCK.

Wdyt?


-1 to stopping Tomcat 9.0.x support.

No interest in supporting 10.0.x

This has been discussed at length previously. Those discussions can be 
found in the archives.


The short version is:
- Tomcat 9.x (Java EE8) will be maintained for the foreseeable future at
  it is the last branch to support Java EE.
- Jakarta EE 9 (Tomcat 10.0) was a transition release that we only ever
  intended to maintain for as long as it took for Jakarta EE 10 (Tomcat
  10.1) to reach stability

Mark

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

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

[Mark Thomas]

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

Mark,

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

sessionAttributeNameFilter="customer"


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


Mark



so like this?...




   

   
 
 

 
   
 
 
 
 
   

   


   
  





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

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

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

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

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

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


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


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

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


https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html

Search for sessionAttributeNameFilter

Mark

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

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


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



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

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

[Mark Thomas]

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

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

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

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


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


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

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


https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html

Search for sessionAttributeNameFilter

Mark

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

Re: Instruct the tomcat source builders before the build process for tomcat source 8.5.100

[Mark Thomas]

On 22/03/2024 10:54, Koteswararao Gundapaneni wrote:

Hi,

While building the tomcat source 8.5.100 its giving an error with java 7

below is the error

ANT_OPTS is set to  -Djava.security.manager=allow
Error occurred during initialization of VM
java.lang.UnsupportedClassVersionError: allow : Unsupported major.minor
version 52.0

in Building.txt file it has the following instruction

  3. Install the JDK according to the instructions included with the release.

so if am not wrong, we could suggest java11 is required for the build
process in the instructions given


Yes, you are wrong.

PLEASE read the documentation first. Specifically this sentence from 
BUILDING.txt



Download a version 11 or later of Java Development Kit...


Mark

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

Re: Regression in mutual authentication in 9.0.86+?

[Mark Thomas]

On 21/03/2024 16:12, Amit Pande wrote:

Thank you Mark for your inputs.

Upon further debugging, it looks like the issue we ran into is also with the 
reloading of SSL context.

Test execution sequence:
1. Add a trusted CA in Tomcat's trust store.
2. The SSL context is reloaded if any of the trust/key store has changes.
3. Perform a mutual client authentication using a client certificate signed by 
the CA used in step 1.

Still a bit puzzled in such a case there was no SSL handshake failure at Tomcat 
level but request made it to application and failed (due to empty 
javax.servlet.request.X509Certificate).


It sounds like you have optional certificate verification enabled.


One follow-up question:

Are we planning to have an immediate 9.0.88 release, or it will be regular 
cadence? Asking because the versions until 9.0.85 have vulnerabilities reported 
and this regression might potentially block the upgrade to 9.0.86/87.


This fix will be picked up in the April release round.

Mark



Lastly, I wholeheartedly echo the gratitude many have expressed around the 
awesome Tomcat leads.

Thanks,
Amit


-Original Message-
From: Mark Thomas 
Sent: Monday, March 18, 2024 4:41 AM
To: users@tomcat.apache.org
Subject: Re: Regression in mutual authentication in 9.0.86+?


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



I've just tested 9.0.x and mutual TLS authentication appears to be working as 
expected.

I suggest starting with testing a simple JSP that echoes that attribute and if 
you still see the issue, provide us with your configuration. Note that the 
issue may be related to the certs you are using so the configuration 
information should include steps to recreate the TLS certs with keystore, 
OpenSSL or similar.

On 15/03/2024 00:48, Amit Pande wrote:

Hello all,

I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with 9.0.87 
too).

Some of our tests which involve on mutual authentication ("certificateVerification = 
optional") have started to fail.

In tests where the client does pass the certificate, I didn't see any SSL handshake 
errors (with SSL handshake debugging enabled) but 
"javax.servlet.request.X509Certificate" attribute wasn't set. This is the 
attribute the application needs for further validations.


Have you confirmed that the certificate was sent from the client?


Could anyone please give pointers on how to debug this further?

Any code pointers where Tomcat sets this 
"javax.servlet.request.X509Certificate" attribute?


git clone
grep


Also, one more question - with optional certificate verification, the 
connection doesn't fail if certificate is not passed. But connection will fail 
if SSL handshake fails when a certificate is passed by client, is that correct 
understanding?


Yes, that is what I would expect.

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

[ANN] Apache Tomcat 11.0.0-M18 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M18 (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-M18 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-M17 include:


- Reduce minimum Java version to Java 17

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

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

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-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

Re: [VOTE] Release Apache Tomcat 10.1.20

[Mark Thomas]

On 19/03/2024 13:52, Christopher Schultz wrote:


The proposed 10.1.20 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 10.1.20


Tests pass on Linux, Windows and MacOS (M1).

The build is reproducible.

Mark

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

Re: [VOTE] Release Apache Tomcat 8.5.100

[Mark Thomas]

On 19/03/2024 14:23, Christopher Schultz wrote:


The proposed 8.5.100 release is:
[ ] Broken - do not release
[X] Stable - go ahead and release as 8.5.100 (stable)


Tests pass on Linux, Windows and MacOS (M1).

The build is reproducible.

Mark

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

Re: What future plans are for Tomcat authentication

[Mark Thomas]

On 20/03/2024 06:22, Mircea Butmalai wrote:




Questions are:

   1.  Is Jakarta Authentication specification going to replace the 
authentication part of Jakarta Servlet specification?


Unlikely.


   2.  Are current authenticatiors from Tomcat (FORM, SPNEGO, SSL, HTTP DIGEST, 
HTTP BASIC, SSO) going to be implemented as Jakarta Authentication providers in 
future versions of Tomcat?


This has been discussed in the past but there is little motivation to do 
so as there are no obvious benefits and possible negative performance 
impacts.



   3.  Is any effort to introduce in Jakarta standards + Tomcat an authentcator 
of type 2FA?


No plans I am aware of.

Mark

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

Re: PKCS#8 encryption algorithm unrecognized

[Mark Thomas]

On 19/03/2024 18:18, Timothy Resh wrote:





where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below. I have read some of the
https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask for
help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?


Please provide a set of OpenSSL commands that create a problematic, 
self-signed certificate for localhost. This will save us a *lot* of time.


Mark




Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
Caused by: java.lang.IllegalArgumentException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1332)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1009)
... 13 more
Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:379)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141)
at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:108)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268)
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465)
... 19 more
15-Mar-2024 18:27:37.636 INFO [main]
org.apache.catalina.startup.Catalina.load Server initialization in [1655]
milliseconds



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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

[Mark Thomas]

On 19/03/2024 07:54, Ivano Luberti wrote:

Could there be a regression also in 9.0.86


Yes. It will be fixed in 9.0.88.

Mark



Because I had a similar issue (reload tls didn't work) but It was the 
first time I was doing that on that tomcat instance and I  had assumed 
there was some misconfiguration, even though certificates where server 
correctly but the wrong expiration date and after restarting tomcat the 
certificates were served with correct dates


Il 18/03/2024 21:20, Mark Thomas ha scritto:

On 18/03/2024 08:21, Mark Thomas wrote:

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

   I've spent a few hours scratching my head and then diving into 
the source code of 10.1.19 to figure out what's going on.


Could you test with 10.1.18? I'm wondering if the user provided 
SSLContext changes in 10.1.19 have triggered a regression.


Never mind. I've just confirmed that those changes did trigger a 
regression. I'll commit a fix shortly and it will be in the next round 
of releases.


Mark




Mark



   I'm using the /TLSCertificateReloadListener/ 
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> to reload files that will be (eventually) managed by Let's Encrypt.


   Although it does detect the expiration and log that things were 
reloaded, the new files are never read and the old cert & key are 
used forever, causing the trigger to reoccur again and again.


   The only way I can get the system to function correctly is if I, 
during debugging in Eclipse with the matching Tomcat source, null 
out the "sslContext" on line 102 of AbstractJsseEndpoint.


   From what I can tell, the SSLHostConfigCertificate objects keep a 
copy of an SSLContext and during the JMX unregister and register the 
same SSLContext is transferred, which never takes in the same files.


   From my limited knowledge, it appears the files will never be 
loaded unless a new instance of SSLContext is created.


   I've tried both APR (OpenSSL) and native JSSE configurations. One 
thing of note - during testing, I'm only using PEM-based cert and 
key files (no CA).


   I have tried writing my own /TLSCertificateReloadListener/ 
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> implementation but have found no clear way to null the SSLContext of the (determined expired) SSLHostConfigCertificate objects to allow a reload.


   I appreciate any suggestions!

-- Justin



-
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: (tomcat) branch main updated: IDE says this is no longer required

[Mark Thomas]

On 18/03/2024 22:18, Rémy Maucherat wrote:

On Mon, Mar 18, 2024 at 9:30 PM Mark Thomas  wrote:


On 18/03/2024 20:24, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
   new 1972d821a0 IDE says this is no longer required
1972d821a0 is described below

commit 1972d821a093002328e7a43c4a7e2ef1fb017af2
Author: Mark Thomas 
AuthorDate: Mon Mar 18 20:24:07 2024 +

  IDE says this is no longer required


Just realised this was new rather than old. I'm guessing you are
compiling with Java 22 in the IDE which is why you need this?


Yes, it's an IDE warning.


No problem. I'll revert my change.

Mark

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

Re: (tomcat) branch main updated: IDE says this is no longer required

[Mark Thomas]

On 18/03/2024 20:24, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/main by this push:
  new 1972d821a0 IDE says this is no longer required
1972d821a0 is described below

commit 1972d821a093002328e7a43c4a7e2ef1fb017af2
Author: Mark Thomas 
AuthorDate: Mon Mar 18 20:24:07 2024 +

 IDE says this is no longer required


Just realised this was new rather than old. I'm guessing you are 
compiling with Java 22 in the IDE which is why you need this?


Mark


---
  java/org/apache/tomcat/util/net/AbstractEndpoint.java | 1 -
  1 file changed, 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/net/AbstractEndpoint.java 
b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
index 2c8a77ddd2..b63a493c27 100644
--- a/java/org/apache/tomcat/util/net/AbstractEndpoint.java
+++ b/java/org/apache/tomcat/util/net/AbstractEndpoint.java
@@ -1240,7 +1240,6 @@ public abstract class AbstractEndpoint {
  this.executor = null;
  if (executor instanceof ThreadPoolExecutor) {
  //this is our internal one, so we need to shut it down
-@SuppressWarnings("resource")
  ThreadPoolExecutor tpe = (ThreadPoolExecutor) executor;
  tpe.shutdownNow();
  long timeout = getExecutorTerminationTimeoutMillis();


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



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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

[Mark Thomas]

On 18/03/2024 08:21, Mark Thomas wrote:

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

   I've spent a few hours scratching my head and then diving into the 
source code of 10.1.19 to figure out what's going on.


Could you test with 10.1.18? I'm wondering if the user provided 
SSLContext changes in 10.1.19 have triggered a regression.


Never mind. I've just confirmed that those changes did trigger a 
regression. I'll commit a fix shortly and it will be in the next round 
of releases.


Mark




Mark



   I'm using the /TLSCertificateReloadListener/ 
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> to reload files that will be (eventually) managed by Let's Encrypt.


   Although it does detect the expiration and log that things were 
reloaded, the new files are never read and the old cert & key are used 
forever, causing the trigger to reoccur again and again.


   The only way I can get the system to function correctly is if I, 
during debugging in Eclipse with the matching Tomcat source, null out 
the "sslContext" on line 102 of AbstractJsseEndpoint.


   From what I can tell, the SSLHostConfigCertificate objects keep a 
copy of an SSLContext and during the JMX unregister and register the 
same SSLContext is transferred, which never takes in the same files.


   From my limited knowledge, it appears the files will never be 
loaded unless a new instance of SSLContext is created.


   I've tried both APR (OpenSSL) and native JSSE configurations. One 
thing of note - during testing, I'm only using PEM-based cert and key 
files (no CA).


   I have tried writing my own /TLSCertificateReloadListener/ 
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> implementation but have found no clear way to null the SSLContext of the (determined expired) SSLHostConfigCertificate objects to allow a reload.


   I appreciate any suggestions!

-- Justin



-
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: problems with partitioned cookies

[Mark Thomas]

On 18/03/2024 15:16, info@klawitter.de wrote:


What am I doing wrong here? (Tomcat 9.0.82)


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Search for "partitioned"

The problem is you are using Tomcat 9.0.82. Support for a default 
partitioned attribute wasn't added until 9.0.85.


Mark

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

Re: Regression in mutual authentication in 9.0.86+?

[Mark Thomas]

I've just tested 9.0.x and mutual TLS authentication appears to be 
working as expected.


I suggest starting with testing a simple JSP that echoes that attribute 
and if you still see the issue, provide us with your configuration. Note 
that the issue may be related to the certs you are using so the 
configuration information should include steps to recreate the TLS certs 
with keystore, OpenSSL or similar.


On 15/03/2024 00:48, Amit Pande wrote:

Hello all,

I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with 9.0.87 
too).

Some of our tests which involve on mutual authentication ("certificateVerification = 
optional") have started to fail.

In tests where the client does pass the certificate, I didn't see any SSL handshake 
errors (with SSL handshake debugging enabled) but 
"javax.servlet.request.X509Certificate" attribute wasn't set. This is the 
attribute the application needs for further validations.


Have you confirmed that the certificate was sent from the client?


Could anyone please give pointers on how to debug this further?

Any code pointers where Tomcat sets this 
"javax.servlet.request.X509Certificate" attribute?


git clone
grep


Also, one more question - with optional certificate verification, the 
connection doesn't fail if certificate is not passed. But connection will fail 
if SSL handshake fails when a certificate is passed by client, is that correct 
understanding?


Yes, that is what I would expect.

Mark

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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

[Mark Thomas]

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

   I've spent a few hours scratching my head and then diving into the 
source code of 10.1.19 to figure out what's going on.


Could you test with 10.1.18? I'm wondering if the user provided 
SSLContext changes in 10.1.19 have triggered a regression.


Mark



   I'm using the /TLSCertificateReloadListener/ 
 to reload files that will be (eventually) managed by Let's Encrypt.


   Although it does detect the expiration and log that things were 
reloaded, the new files are never read and the old cert & key are used 
forever, causing the trigger to reoccur again and again.


   The only way I can get the system to function correctly is if I, 
during debugging in Eclipse with the matching Tomcat source, null out 
the "sslContext" on line 102 of AbstractJsseEndpoint.


   From what I can tell, the SSLHostConfigCertificate objects keep a 
copy of an SSLContext and during the JMX unregister and register the 
same SSLContext is transferred, which never takes in the same files.


   From my limited knowledge, it appears the files will never be loaded 
unless a new instance of SSLContext is created.


   I've tried both APR (OpenSSL) and native JSSE configurations. One 
thing of note - during testing, I'm only using PEM-based cert and key 
files (no CA).


   I have tried writing my own /TLSCertificateReloadListener/ 
 implementation but have found no clear way to null the SSLContext of the (determined expired) SSLHostConfigCertificate objects to allow a reload.


   I appreciate any suggestions!

-- Justin



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

Re: Very sporadic test failures in org.apache.catalina.core.TestAsyncContextImpl for TC 8.5 and 9

[Mark Thomas]

On 08/03/2024 20:28, Rainer Jung wrote:
Again, this is not a new failure and it happens extremely infrequent. 
Observed with JSSE on various Linux distributions and with various JVM 
versions and vendors. Only observed for TC 8.5 and 9, but for 10.1 and 
11 the unit tests are run with much fewer JVM combinations so I can not 
exclude the problem might happen there as well.


Looks like a timing issue when we have a non-container thread still 
accessing the AsyncContext (it shouldn't do that).


The test acknowledged the problem but you found another fisalure mode 
that wasn't handled. It now is. Hopefully, these tests should be more 
reliable going forwards.


Mark




This info is not intended to prevent a release.

The typical situation is:

Testcase: testBug49567 took 21.162 sec
     FAILED
expected:<...alse2true3true4true5[false]> but 
was:<...alse2true3true4true5[]>
junit.framework.AssertionFailedError: 
expected:<...alse2true3true4true5[false]> but 
was:<...alse2true3true4true5[]>
     at 
org.apache.catalina.core.TestAsyncContextImpl.testBug49567(TestAsyncContextImpl.java:163)
     at 
java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)


The execution log contains:

22-Feb-2024 11:19:03.617 INFO [main] 
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case 
[testBug49567]
22-Feb-2024 11:19:03.626 INFO [main] 
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["http-nio-127.0.0.1-auto-11"]
22-Feb-2024 11:19:03.627 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Tomcat]
22-Feb-2024 11:19:03.627 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet 
engine: [Apache Tomcat/9.0.86]
22-Feb-2024 11:19:03.640 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]
Exception in thread "Thread-9" java.lang.NullPointerException: Cannot 
invoke "org.apache.catalina.connector.Request.getCoyoteRequest()" 
because "this.request" is null
     at 
org.apache.catalina.core.AsyncContextImpl.isStarted(AsyncContextImpl.java:295)
     at 
org.apache.catalina.connector.Request.isAsyncStarted(Request.java:1715)
     at 
org.apache.catalina.connector.RequestFacade.isAsyncStarted(RequestFacade.java:749)
     at 
org.apache.catalina.core.TestAsyncContextImpl$Bug49567Servlet$1$1.run(TestAsyncContextImpl.java:383)

     at java.base/java.lang.Thread.run(Thread.java:1583)
22-Feb-2024 11:19:24.685 INFO [main] 
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]
22-Feb-2024 11:19:24.693 INFO [main] 
org.apache.catalina.core.StandardService.stopInternal Stopping service 
[Tomcat]
22-Feb-2024 11:19:24.729 INFO [main] 
org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]
22-Feb-2024 11:19:24.739 INFO [main] 
org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler 
["http-nio-127.0.0.1-auto-11-46529"]



or as a variation:

08-Mar-2024 14:44:59.132 INFO [main] 
org.apache.catalina.startup.LoggingBaseTest.setUp Starting test case 
[testBug49528]
08-Mar-2024 14:44:59.141 INFO [main] 
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["http-nio2-127.0.0.1-auto-10"]
08-Mar-2024 14:44:59.151 INFO [main] 
org.apache.catalina.core.StandardService.startInternal Starting service 
[Tomcat]
08-Mar-2024 14:44:59.151 INFO [main] 
org.apache.catalina.core.StandardEngine.startInternal Starting Servlet 
engine: [Apache Tomcat/9.0.86sp1]
08-Mar-2024 14:44:59.170 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
["http-nio2-127.0.0.1-auto-10-37101"]
java.lang.NullPointerException: Cannot invoke 
"org.apache.catalina.connector.Request.getCoyoteRequest()" because 
"this.request" is null
     at 
org.apache.catalina.core.AsyncContextImpl.isStarted(AsyncContextImpl.java:295)
     at 
org.apache.catalina.connector.Request.isAsyncStarted(Request.java:1715)
     at 
org.apache.catalina.connector.RequestFacade.isAsyncStarted(RequestFacade.java:749)
     at 
org.apache.catalina.core.TestAsyncContextImpl$Bug49528Servlet$1.run(TestAsyncContextImpl.java:303)
     at 
org.apache.catalina.core.AsyncContextImpl$RunnableWrapper.run(AsyncContextImpl.java:543)
     at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
     at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
     at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)

     at java.base/java.lang.Thread.run(Thread.java:1583)
08-Mar-2024 14:45:00.196 INFO [main] 
org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler 
["http-nio2-127.0.0.1-auto-10-37101"]
08-Mar-2024 14:45:00.198 INFO [main] 

Re: Plans for 10.1.x and 8.5.x release?

[Mark Thomas]

On 15/03/2024 12:08, Koteswararao Gundapaneni wrote:

Hi

Innovations are on the way for both 10.1.x and 8.5.x


OK. I'll bite. What innovations?

Mark




regards,
Koti

On Fri, Mar 15, 2024 at 4:53 AM Mark Thomas  wrote:


Chris,

Just wondering what your thinking was for the March releases of 10.1.x
and 8.5.x

Mark

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






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

Plans for 10.1.x and 8.5.x release?

[Mark Thomas]

Chris,

Just wondering what your thinking was for the March releases of 10.1.x 
and 8.5.x


Mark

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

Re: Requesting as I had been agreed to commit from a contributor role

[Mark Thomas]

On 15/03/2024 01:41, koteswara Rao Gundapaneni wrote:

Ok let me know I can use the below email as the future mailing address


apache.tomcat.k...@gmail.com


Something like that


Unsubscribe your old address.

Subscribe your new address.

Full instructions can be found at https://tomcat.apache.org/lists.html

Mark





Regards
Koti



On Fri, 15 Mar 2024, 00:35 Christopher Schultz, <
ch...@christopherschultz.net> wrote:


Koteswararao,

On 3/14/24 14:21, Mark Thomas wrote:

On 14/03/2024 13:43, koteswara Rao Gundapaneni wrote:



On Thu, 14 Mar 2024, 00:28 koteswara Rao Gundapaneni,
mailto:koti.gundapan...@gmail.com>> wrote:


 HI Tomcat PMC,

 Please ensure I had showing my interest as a committer as I have
 been passed my contribution status from a range of having said
 that few contributions


Simply saying I have been showing my interest to work as committer


Please approve my icla


There is nothing to approve. You submitted your ICLA. It has been filed
by the ASF secretary.

I'll note that:
- no-one asked you to file an ICLA
- there was no need for you to file an ICLA
- the only thing filing an ICLA achieved was wasting the precious
resource of volunteer time

I *strongly* urge you to read the advice (including the references to
how the ASF works) you have been given on and off list, stop wasting
precious volunteer time and think very carefully before you post
anything else to a Tomcat mailing list.


Definitely read ASF How It Works, specifically the section on
Meritocracy[1]. You cannot simply ask to become a committer on a
project. Instead, you have to demonstrate to the existing project
participants that you *deserve* to be /invited/ as a committer.

So far, the weird series of PRs and emails you have sent are not making
you look good.

I'm not trying to be mean. I'm trying to be honest and use simple language.

-chris

[1] https://www.apache.org/foundation/how-it-works/#meritocracy

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






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

[ANN] Apache Tomcat 11.0.0-M18 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M18 (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-M18 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-M17 include:


- Reduce minimum Java version to Java 17

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

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

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-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

[ANN] Apache Tomcat 11.0.0-M18 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M18 (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-M18 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-M17 include:


- Reduce minimum Java version to Java 17

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

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

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[ANN] Apache Tomcat 11.0.0-M18 (alpha) available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M18 (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-M18 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-M17 include:


- Reduce minimum Java version to Java 17

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

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

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-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

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

[Mark Thomas]

CVE-2024-23672 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
It was possible for a WebSocket client to keep a WebSocket connection 
open leading to increased resource consumption.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

History:
2024-03-13 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

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

[Mark Thomas]

CVE-2024-24549 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
When processing an HTTP/2 request, if the request exceeded any of the 
configured limits for headers, the associated HTTP/2 stream was not 
reset until after all of the headers had been processed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Bartek Nowotarski (https://nowotarski.info/).


History:
2024-03-13 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

Re: Requesting as I had been agreed to commit from a contributor role

[Mark Thomas]

On 14/03/2024 13:43, koteswara Rao Gundapaneni wrote:



On Thu, 14 Mar 2024, 00:28 koteswara Rao Gundapaneni, 
mailto:koti.gundapan...@gmail.com>> wrote:



HI Tomcat PMC,

Please ensure I had showing my interest as a committer as I have
been passed my contribution status from a range of having said
that few contributions 




Simply saying I have been showing my interest to work as committer


Please approve my icla


There is nothing to approve. You submitted your ICLA. It has been filed 
by the ASF secretary.


I'll note that:
- no-one asked you to file an ICLA
- there was no need for you to file an ICLA
- the only thing filing an ICLA achieved was wasting the precious
  resource of volunteer time

I *strongly* urge you to read the advice (including the references to 
how the ASF works) you have been given on and off list, stop wasting 
precious volunteer time and think very carefully before you post 
anything else to a Tomcat mailing list.


Mark

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

Re: reloading context with manager-script

[Mark Thomas]

On 12/03/2024 13:47, Christopher Schultz wrote:

Greg and Mark,

On 3/12/24 05:00, Greg Huber wrote:

On 11/03/2024 18:17, Christopher Schultz wrote:

Mark,

On 3/10/24 08:49, Mark Thomas wrote:

On 10/03/2024 10:50, Greg Huber wrote:

Hello,

Using http://tomcat/manager-app/text/reload?path=/

When I reload an application (in java), I get a reply

OK - Reloaded application at context path [/]

but when the application is not present I get this reply:

FAIL - No context exists named []

Is it intentional that the fail shows the ascii code rather than 
the slash like on the OK?


Yes.

If the provided context exists then we know that the name is HTML 
safe since all valid context names are HTML safe. In this case there 
is no escaping.


If the context does not exist then the provided content name may not 
be HTML safe (it could be a deliberate XSS attempt) hence it is 
escaped.


What is the Content-Type of the response? The URL implies that it's a 
text interface, not HTML.

 >
 > Running it on the browser I get
 >
 > Content-Type : text/plain;charset=utf-8

Yeah, that's what I was expecting.

I think HTML escaping is not appropriate, here.


Agreed. The challenge is that you don't have the context to determine if 
the request originates from the HTMLManagerServlet.


It may be possible to refactor the escaping so it happens in 
HTMLManagerServlet instead.


Mark

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

Re: What does the number preceding the catalina.org.apache.juli.AsyncFileHandler in Tomcat's conf/logging.properties mean?

[Mark Thomas]

On 14/03/2024 11:51, Vincent Daniel wrote:

Thank you so much.
I am ashamed that I did not read the documentation carefully.


No problem. It is only a single line in the docs and it helps a lot if 
you know what you are looking for.


Mark



On Thu, Mar 14, 2024 at 7:46 PM Mark Thomas  wrote:


On 14/03/2024 11:36, Vincent Daniel wrote:

Hi, community

When I configured Tomcat logs, I found the following configuration in
logging.properties

1catalina.org.apache.juli.AsyncFileHandler
2localhost.org.apache.juli.AsyncFileHandler
3manager.org.apache.juli.AsyncFileHandler
4host-manager.org.apache.juli.AsyncFileHandler

I am not sure what the numbers in front of them mean?

I checked the Tomcat documentation > Logging chapter and found no
relevant instructions. I also searched the Tomcat source code
repository on Github, and only found document-related content.

Can someone explain this please?


https://tomcat.apache.org/tomcat-11.0-doc/logging.html

Search for the word "prefix".

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: What does the number preceding the catalina.org.apache.juli.AsyncFileHandler in Tomcat's conf/logging.properties mean?

[Mark Thomas]

On 14/03/2024 11:36, Vincent Daniel wrote:

Hi, community

When I configured Tomcat logs, I found the following configuration in
logging.properties

1catalina.org.apache.juli.AsyncFileHandler
2localhost.org.apache.juli.AsyncFileHandler
3manager.org.apache.juli.AsyncFileHandler
4host-manager.org.apache.juli.AsyncFileHandler

I am not sure what the numbers in front of them mean?

I checked the Tomcat documentation > Logging chapter and found no
relevant instructions. I also searched the Tomcat source code
repository on Github, and only found document-related content.

Can someone explain this please?


https://tomcat.apache.org/tomcat-11.0-doc/logging.html

Search for the word "prefix".

Mark

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

Re: Requesting as I had been agreed to commit from a contributor role

[Mark Thomas]

Koteswararao,

This message makes no sense.

Please follow the advice you have been given multiple times off-list to 
either post in your native language and let recipients use Google 
translate if required or use Google translate yourself.


If you continue to ignore the advice you have been given, you will be 
blocked from posting to all Tomcat mailing lists.


Mark


On 14/03/2024 11:16, koteswara Rao Gundapaneni wrote:

On Thu, 14 Mar 2024, 00:28 koteswara Rao Gundapaneni, <
koti.gundapan...@gmail.com> wrote:



HI Tomcat PMC,


Please ensure I had showing my interest as a committer as I have been
passed my contribution status from a range of having said that few
contributions

regards,
Koteswararao







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

Re: (tomcat-tck) 02/04: Update to 11.0.0-M18 release and EL API 6.0.0

[Mark Thomas]

FYI, 11.0.0-M18 passes the EL 6.0 TCK and I'll be using that (rather 
than the previous 11.0.0-M18-SNAPSHOT) to provide the certified 
implementation I need to complete the EL 6.0 release over at Eclipse.


Mark


On 14/03/2024 10:12, ma...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

markt pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat-tck.git

commit f8f0e68378d5677594453ca912d4fbb9da0865f0
Author: Mark Thomas 
AuthorDate: Thu Mar 14 10:09:17 2024 +

 Update to 11.0.0-M18 release and EL API 6.0.0
---
  pom.xml | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/pom.xml b/pom.xml
index b4498ba..72e0b0f 100644
--- a/pom.xml
+++ b/pom.xml
@@ -31,13 +31,13 @@
  17
  
  

-11.0.0-M18-SNAPSHOT
+11.0.0-M18
  
  

  6.0.0
-6.0.0-SNAPSHOT
+6.0.0
  6.1.0-SNAPSHOT
-4.0.0-SNAPSHOT
+4.0.0
  10.0.0-SNAPSHOT
  
  



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



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

[VOTE][RESULT} Release Apache Tomcat 11.0.0-M18

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, remm, schultz, lihan

Non-Binding:
+1: Dimitris Soumis

The vote therefore passes.

Thanks to everyone who contributed to this release.

Mark


On 09/03/2024 18:52, Mark Thomas wrote:

The proposed Apache Tomcat 11.0.0-M18 release is now available for
voting.

Apache Tomcat 11.0.0-M18 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 the previous milestone include:


- Reduce minimum Java version to Java 17

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

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

For full details, see the change log:
https://nightlies.apache.org/tomcat/tomcat-11.0.x/docs/changelog.html

Applications that run on Tomcat 9 and earlier will not run on Tomcat 11 
without changes. Java EE applications designed for Tomcat 9 and earlier 
may be placed in the $CATALINA_BASE/webapps-javaee directory and Tomcat 
will automatically convert them to Jakarta EE and copy them to the 
webapps directory. Applications using deprecated APIs may require 
further changes.


It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-11/v11.0.0-M18/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1484

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M18
eee0dbb29048a60ee2c85ebcb9abb1750046c0bf

The proposed 11.0.0-M18 release is:
[ ] -1 Broken - do not release
[ ] +1 Alpha  - go ahead and release as 11.0.0-M18

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



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

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

[Mark Thomas]

CVE-2024-23672 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
It was possible for a WebSocket client to keep a WebSocket connection 
open leading to increased resource consumption.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

History:
2024-03-13 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

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

[Mark Thomas]

CVE-2024-24549 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
When processing an HTTP/2 request, if the request exceeded any of the 
configured limits for headers, the associated HTTP/2 stream was not 
reset until after all of the headers had been processed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Bartek Nowotarski (https://nowotarski.info/).


History:
2024-03-13 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

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

[Mark Thomas]

CVE-2024-23672 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
It was possible for a WebSocket client to keep a WebSocket connection 
open leading to increased resource consumption.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

History:
2024-03-13 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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

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

[Mark Thomas]

CVE-2024-23672 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
It was possible for a WebSocket client to keep a WebSocket connection 
open leading to increased resource consumption.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

History:
2024-03-13 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

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

[Mark Thomas]

CVE-2024-24549 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
When processing an HTTP/2 request, if the request exceeded any of the 
configured limits for headers, the associated HTTP/2 stream was not 
reset until after all of the headers had been processed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Bartek Nowotarski (https://nowotarski.info/).


History:
2024-03-13 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

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

[Mark Thomas]

CVE-2024-24549 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
When processing an HTTP/2 request, if the request exceeded any of the 
configured limits for headers, the associated HTTP/2 stream was not 
reset until after all of the headers had been processed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Bartek Nowotarski (https://nowotarski.info/).


History:
2024-03-13 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: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.

[Mark Thomas]

On 13/03/2024 14:38, Rémy Maucherat wrote:

 wrote:





1. A longer default nag-duration


That's a good start. If it is meant to be enabled by default, I would
like a value that is long enough so that it is almost certain there's
an issue. 2 years ?

Rémy


2. Add an explicit "disable" (e.g. -1)


I was thinking yes to this and setting it to -1 by default.


3. Disable the feature by default

4. Remove this feature entirely

The target for this was really 8.5 which will immediately go
out-of-support once 8.5.100 is released. So really the default for
8.5.100 should be "nag immediately", but we can't expect that anybody
really uses the out-of-the-box server.xml without any customizations, so
specifically setting the duration to some small number of days in
server.xml isn't going to have any effect.


The more I think about this the more I wonder if some further tweaks are 
required.


This check only runs at startup. There are some (very) long running 
Tomcat instances out there. Is on startup enough? Should this check be 
periodic? If yes, how periodic? Once a day? Probably whatever frequency 
we went for with the TLS reload warnings would be about right.


Mark

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

Re: [VOTE] Release Apache Tomcat 9.0.87

[Mark Thomas]

On 11/03/2024 11:09, Rémy Maucherat wrote:


The proposed 9.0.87 release is:
[ ] -1, Broken - do not release
[X] +1, Stable - go ahead and release as 9.0.87


Tests pass on Linux, Windows and MacOS (M1).

I'm currently unable to test on Intel MacOS due to security software 
recently installed by $dayjob.


The build is repeatable.

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

Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.

[Mark Thomas]

On 11/03/2024 21:38, schu...@apache.org wrote:

This is an automated email from the ASF dual-hosted git repository.

schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git

commit 3ab883aa746a5c577efa39d9080858e53ca77da6
Author: Christopher Schultz 
AuthorDate: Mon Mar 11 17:38:01 2024 -0400

 Add checking for the age of the Tomcat version running and warn if it's 
getting old.


How do I disable this check if I don't want to use it? I'd expect 
something like set it to "-1".


Mark

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

Drop jspxml.dtd and jspxml.xsd

[Mark Thomas]

The jspxml files are located in the jakarta.servlet.jsp.resources packages.

They do not appear to have been updated since Tomcat 5.

They are not part of the JSP JAR provided by Jakarta EE. I can't find 
them anywhere in the Jakarta EE repositories.


I'd like to drop them in Tomcat 11. I will do so for the next release 
unless I hear any objections.


Mark


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