Jakarta Authentication TCK

[Mark Thomas]

Hi all,

The current status is that Tomcat 11.0.x passes the Jakarta 
Authentication TCK apart from tests that are currently being challenged. 
Those challenges are:


1. All the SOAP tests since SOAP support was removed from Jakarta EE for 
Jakarta EE 11.


2. The ServletProfileSPITest#CheckMsgInfoKey test since it is hard-coded 
to require Jakarta Authorization


I'm not planning on formally certifying for the Jakarta Authentication API.

Some of the configuration required to get the TCK running seemed a 
little hacky. I have an open issue with the Jakarta Authentication 
project to find out the right way to do things. My hope is that once 
that is resolved, I'll be able to add the Authentication TCK to the 
tomcat-tck project and run it with the others.


Mark


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

Re: (tomcat) branch 11.0.x updated: Ensure ServerAuthModule.initialize() is called with simple registration

[Mark Thomas]

On 17/09/2024 20:11, ma...@apache.org wrote:

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

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


The following commit(s) were added to refs/heads/11.0.x by this push:
  new 9c916c9790 Ensure ServerAuthModule.initialize() is called with simple 
registration
9c916c9790 is described below

commit 9c916c9790ed92681cb2bc2495ef37ead66218b1
Author: Mark Thomas 
AuthorDate: Tue Sep 17 20:11:08 2024 +0100

 Ensure ServerAuthModule.initialize() is called with simple registration


I found this while running the Jakarta Authentication TCK. I'm expecting 
to find a few more issues like this.


The Auth TCK is in a different format to the other TCKs. I want to add 
it to the tomcat-tck repo eventually but I'm not sure of the best way to 
do that right now. My plan is to get the TCK passing locally and then 
figure out the best way to integrate it with the others.


Mark


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

[Mark Thomas]

The following votes were cast:

Binding:
+1: schultz, markt, remm

Non-binding:
+1: dsoumis

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: (tomcat) branch 11.0.x updated: Missing end tag

[Mark Thomas]

On 16/09/2024 15:53, r...@apache.org wrote:

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

remm pushed a commit to branch 11.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/11.0.x by this push:
  new c7b0fa7294 Missing end tag
c7b0fa7294 is described below

commit c7b0fa729434322c3fe408ef8572a4422abdee43
Author: remm 
AuthorDate: Mon Sep 16 16:53:33 2024 +0200

 Missing end tag


Whoops.

Tx.

Mark


---
  webapps/docs/changelog.xml | 1 +
  1 file changed, 1 insertion(+)

diff --git a/webapps/docs/changelog.xml b/webapps/docs/changelog.xml
index 9415f7c1cc..60291eeb5e 100644
--- a/webapps/docs/changelog.xml
+++ b/webapps/docs/changelog.xml
@@ -105,6 +105,7 @@
issues do not "pop up" wrt. others).
  -->
  
+
  

  


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

[Mark Thomas]

On 13/09/2024 20:18, Rémy Maucherat wrote:


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


Tests pass on:
- Linux (OpenSSL 3.0.13 from Ubuntu 24.04)
- Windows (OpenSSL 3.0.14 - Native 1.3.1 binaries)
- MacOS (M1 (OpenSSL 3.3.1)
- MacOS (Intel) (OpenSSL 3.3.1)

The build is cross-platform repeatable.

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

[Mark Thomas]

On 14/09/2024 12:10, Christopher Schultz wrote:

The proposed Apache Tomcat 10.1.30 release is now available for
voting.


+1

Tests pass on:
- Linux (OpenSSL 3.0.13 from Ubuntu 24.04)
- Windows (OpenSSL 3.0.14 - Native 2.0.8 binaries)
- MacOS (Intel) (OpenSSL 3.3.1)
- MacOS (M1 (OpenSSL 3.3.1)

The build is cross-platform repeatable.

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

[Mark Thomas]

On 13/09/2024 19:03, Mark Thomas wrote:


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


Tests pass on:
- Linux (OpenSSL 3.0.13 from Ubuntu 24.04)
- Windows (OpenSSL 3.0.14 - Native 2.0.8 binaries)
- MacOS (Intel) (OpenSSL 3.3.1)
- MacOS (M1 (OpenSSL 3.3.1)

The build is cross-platform repeatable.

Mark

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

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

[Mark Thomas]

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


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

The regression can be worked around by setting:

discardRequestsAndResponses="true"

on the UpgradeProtocol element for HTTP/2.

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


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

- The Apache Tomcat team

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

Re: Future of JNI in Tomcat

[Mark Thomas]

On 12/09/2024 15:15, Rémy Maucherat wrote:

Hi,

This JEP has the potential to have a significant impact with Tomcat's
JNI use starting with Java 26.
https://openjdk.org/jeps/471

Unsafe.invokeCleaner will be removed, which will effectively prevent
using the direct ByteBuffers that are needed for tomcat-native. The
solution is to use a memory segment from FFM, then call
MemorySegment.asByteBuffer, which creates a direct ByteBuffer with a
controllable lifecycle. So using JNI would require FFM and using the
full FFM code instead should make more sense.


+1.


We will of course have to see how things turn out ...


FFM is looking more and more like the way to go.


Another, less problematic, yet still annoying change will be
https://openjdk.org/jeps/472 in Java 24+. Basically, the native access
flag use will become mandatory. This is a bit annoying since it is not
possible to add "--enable-native-access=ALL-UNNAMED" in the default
command line without breaking on older Java.


So we have issues when running older Tomcats that have to work with JREs 
that don't have FFM - hence they need JNI.


We have had issues like this before and have managed to hack around 
them. Maybe it is time for slightly more robust solution. I was thinking 
something like:


- new class in bootstrap JAR with a main method that just returns the 
current major java version as the exit code


- the startup scripts call java with that class and store exit code in a 
variable


- we use that variable to select what to include when composing the main 
command line to start Tomcat.


Mark


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

Possible HTTP/2 regression in Sept releases

[Mark Thomas]

See BZ 69320. I've reproduced the issue on 10.1.x. Haven't tested other 
versions yet or started to look for a root cause. That is next.


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-M25 (beta) available

[Mark Thomas]

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

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

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

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

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

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

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

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

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

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

Enjoy!

- The Apache Tomcat team

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

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

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, remm, rjung

Non-binding:
+1: dsoumis

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

[Mark Thomas]

On 09/09/2024 15:35, Rainer Jung wrote:
Minor nit, irrelevant vor voting: it seems the previous (M24) changelog 
entry has no release date.


Sorry. Should be fixed now.

Mark



Am 09.09.24 um 16:32 schrieb Rainer Jung:

Am 05.09.24 um 15:08 schrieb Mark Thomas:

The proposed Apache Tomcat 11.0.0-M25 release is now available for
voting.

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


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

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

- An Exception being thrown during WebSocket message processing (e.g. in
   a method annotated with @onMessage) should not automatically cause 
the

   connection to close. The application should handle the exception and
   make the decision whether or not to close the connection.

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-M25/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1511

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M25
fafe3dc7a63c12fbb45aa076c90d6a9e7f77e5c8

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


+1

Tested on platforms

- RHEL 6, 7, 8 and 9, SLES 11, 12 and 15

using

- JDK 11, 17, 21, 22, 23 (Release Candidate) and 24 (current EA)

from

- Eclipse Adoptium, Azul Zulu, Amazon Coretto, Oracle, RedHat and 
OpenJDK (for the RC and EA)


where applicable.

Also tested with

- tcnative 1.3.1, tcnative 2.0.8 and panama

based on

- OpenSSL 3.0.15, 3.1.7, 3.2.3 and 3.3.2.

All fine, except for the usual sporadic crashes with tcnative during 
shutdown and also the known bunch of test failures with JDK 24. Of 
course JDK 24 EA problems are not a showstopper in any way.


Thanks for RM!

Best regards,

Rainer


-
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) branch 9.0.x updated: Add lifecycle events, correct activation, use aliases correctly

[Mark Thomas]

On 06/09/2024 16:13, Felix Schumacher wrote:

Nice to see, that plantuml really works.


+1

Thanks again for your help getting it to behave the way we (OK - I) want.


We could use a few shortcuts to make the code more readable(?).

* activating an actor can be done by adding "++" to the message line, so 
instead of writing

     a -> b: message()
     activate b

    we could shorten it to
    a -> b ++: message()

* deactivating an actor directly after a return message, can be 
shortened using "return"


    a <<-- b
    deactivate b

    can be replaced by

     return


Those look good to me. I'll see about making those refactorings.

Another thing worth to mention might be, that the plantuml plug-in in VS 
Code will look at the file ending and expect it to be one of 
|*.wsd|,|*.pu|,|*.puml|,|*.plantuml|,|*.iuml|


I'll change the extension to plantuml - might as well be explicit.

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

[Mark Thomas]

On 06/09/2024 16:43, Christopher Schultz wrote:


Please reply with a +1 for release or +0/-0/-1 with an explanation.


+1

Tests pass on:
- Linux (OpenSSL 3.0.2 from Ubuntu 22.04)
- Windows (OpenSSL 3.0.14 - Native 2.0.8 binaries)
- MacOS (Intel) (OpenSSL 3.3.1)
- MacOS (M1 (OpenSSL 3.3.1)

The build is repeatable but not cross-platform repeatable (my fault - 
sorry - already fixed for 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 9.0.94

[Mark Thomas]

On 05/09/2024 14:58, Rémy Maucherat wrote:


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


Tests pass on:
- Linux (OpenSSL 3.0.2 from Ubuntu 22.04)
- Windows (OpenSSL 3.0.14 - Native 2.0.8 binaries)
- MacOS (Intel) (OpenSSL 3.3.1)
- MacOS (M1 (OpenSSL 3.3.1)

The build is repeatable but not cross-platform repeatable (my fault - 
sorry - already fixed for 9.0.x)


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: Add lifecycle event detail for Server

[Mark Thomas]

On 06/09/2024 12:24, Rémy Maucherat wrote:

On Fri, Sep 6, 2024 at 1:19 PM Mark Thomas  wrote:


On 06/09/2024 12:14, 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 c5334fb785 Add lifecycle event detail for Server
c5334fb785 is described below

commit c5334fb78580f324f58dab4848bea27934a09c86
Author: Mark Thomas 
AuthorDate: Fri Sep 6 12:12:16 2024 +0100

  Add lifecycle event detail for Server


Question.

Do I add this for all the components that implement lifecycle (for
completeness) or do I add a note listing the other components on the
diagram that also use initInternal() and fire lifecycle events for
simplicity / clarity?

I'm currently leaning towards completeness rather than simplicity/clarity.

Thoughts?


The start one seems to have everything but as a result it is more
cluttered. I suppose it is best to have a complete view.


That is what I was thinking. It also makes it more obvious that the 
Adapter and the Protocol don't have lifecycle events.


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: Add lifecycle event detail for Server

[Mark Thomas]

On 06/09/2024 12:14, 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 c5334fb785 Add lifecycle event detail for Server
c5334fb785 is described below

commit c5334fb78580f324f58dab4848bea27934a09c86
Author: Mark Thomas 
AuthorDate: Fri Sep 6 12:12:16 2024 +0100

 Add lifecycle event detail for Server


Question.

Do I add this for all the components that implement lifecycle (for 
completeness) or do I add a note listing the other components on the 
diagram that also use initInternal() and fire lifecycle events for 
simplicity / clarity?


I'm currently leaning towards completeness rather than simplicity/clarity.

Thoughts?

Mark


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

Re: svn commit: r1920023 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml

[Mark Thomas]

On 05/09/2024 22:25, Konstantin Kolinko wrote:

пн, 19 авг. 2024 г. в 14:27, Mark Thomas :


On 19/08/2024 12:23, ma...@apache.org wrote:

Author: markt
Date: Mon Aug 19 11:23:05 2024
New Revision: 1920023

URL: http://svn.apache.org/viewvc?rev=1920023&view=rev
Log:
Add first draft of security model


All,

This is an attempt to document something I think we all instinctively
understand. It is likely that we'll need this, or something like it, to
meet the CRA requirements (or to be more accurate for our downstream
users to meet their CRA requirements).

It is currently not linked from the rest of the Tomcat site. My thinking
was we'd refine it and then link it once we were happy with it.

Feel free to update/comment/etc just like any other site content.


Thank you for starting this work.

BTW, url for the document (if somebody wants to review) is
https://tomcat.apache.org/security-model.html

Some thoughts
- In "Administrative users" there it says "has access to or control over".

I was wondering whether it could be simplified, but I resolved to
leave it as is.

Generally, "read access" should not be allowed to Tomcat configuration
files, as those may contain secrets.

Read access to the binaries generally is safe, but may be used to
determine what version of Tomcat is being used.

If so, are users that have access to those considered as "Administrative users"?


TL;DR: yes.

There are different levels of risk for different files. Users may well 
opt to apply different access controls to different files. Our position 
is (as I understand it) if any of those users can do harm as a result of 
that access then that is not a Tomcat vulnerability. The simplest way to 
express this is to state that any vulnerability that relies on access to 
those files will be rejected.



- Maybe mention the temporary files (temp, work).

Though they are mentioned on the Security Considerations pages.

"temp" is used for Servlet API's file upload support and for the
antiResourceLocking feature. "work" stores compiled code for the web
applications that we consider as "trusted".


Good idea. Done.


- In "Logging" I wonder what "Security-sensitive information" is.


I was trying to distinguish between information an attacker can use to 
gain access (e.g. a password, session ID etc) and everything else.



Non-anonymised information about users' activity is generally
sensitive, and thus are access logs.

We do log IP addresses. We do log "%u" (user name).

In general non-trusted users should not have access to that information.


I'll add a note that the default logs contain PII.


BTW,
generally "non sensitive" data may actually be sensitive, if users may
put sensitive information into it. (E.g. I vaguely remember that I
once saw a system that logged names of users that failed to
authenticate, and some users were typing their passwords into the
username field, resulting in those being logged). (IIUC, %u is safe,
as it logs names of those who have successfully authenticated)


I've seen that too. I've added a note that Tomcat isn't responsible for 
the content of log messages generated by applications so we aren't 
required to sanitize them.



- In Connectors, maybe mention that AJP is essentially plain text, as
well as plain HTTP or plain HTTP/2 (h2c).


I think that is straying more into something that belongs in security 
considerations. I've may an update there that I'll commit once I've 
finished updating this page.



- I wonder whether "Data .. is considered to be untrusted" has further
exceptions.


I couldn't think of any but we can add to it if necessary.


A front proxy may reuse connections to Tomcat to process requests from
different clients. We do expect the data to be structurally correct.


I've added paragraph to say that it is the client's problem if it 
presents malformed data and doesn't handle the response correctly.



Minor
- I wonder whether the "apart from" clause (in Connectors) is
understandable. I considered rewriting it as "with exception of the
following".


To a native speaker there isn't any difference but happy to change this 
if it is more likely to be understood by a wider audience.



Generic, beyond bounds of this document.
- When I think about what "trust" actually means and implies, it
inspires some related thoughts / topics.

(How the trust can be enforced. What happens when trust is breached. Etc.)


Fortunately that is not our problem ;)


- I wonder whether there exists a "Security Model" document for a
generic web application.


I haven't seen one.

As always, thank you for the thorough review.

Mark

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

[VOTE] Release Apache Tomcat 11.0.0-M25

[Mark Thomas]

The proposed Apache Tomcat 11.0.0-M25 release is now available for
voting.

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


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

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

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

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-M25/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1511

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M25
fafe3dc7a63c12fbb45aa076c90d6a9e7f77e5c8

The proposed 11.0.0-M25 release is:
[ ] -1 Broken - do not release
[ ] +1 Beta   - go ahead and release as 11.0.0-M25

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

Re: (tomcat) branch main updated: Add instructions to edit via POPEditor.com to all translated files

[Mark Thomas]

On 03/09/2024 18:51, Konstantin Kolinko wrote:

вт, 3 сент. 2024 г. в 19:40, Mark Thomas :


commit ab21ffadbdc2b8d8cb8db23758aa74ba786cdf4c
Author: Mark Thomas 
AuthorDate: Tue Sep 3 17:08:09 2024 +0100

  Add instructions to edit via POPEditor.com to all translated files


I haven't run an import with this commit in place yet. I wanted to give
folks a chance to review the text before it was added to every
translated file.



+static void insertEditInstructions(Writer w) throws IOException {
+w.write(System.lineSeparator());
+w.write("# Do not edit this file directly. Translations are managed via 
poeditor.");
+w.write(System.lineSeparator());
+w.write("# Join to edit translations: 
https://poeditor.com/join/project/NUTIjDWzrl";);
+w.write(System.lineSeparator());
+w.write("# View the translations: 
https://poeditor.com/projects/view?id=221603";);
+w.write(System.lineSeparator());


I think it'd be better to refer to our own page instead of a direct
link to a 3rd party site.

a, Source code lives for years,and links may become outdated.
b. A link without accompanying instructions may be not helpful.

Maybe refer to the existing "Get Involved" page (improve it?) instead
of the Wiki one.
https://tomcat.apache.org/getinvolved.html

BTW, permalink to the Wiki page is
https://cwiki.apache.org/confluence/x/vIPzBQ


All good points. I'll get that done before I tag this month's release 
(but probably won't run the import to update all the files until the 
October release).


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: Add instructions to edit via POPEditor.com to all translated files

[Mark Thomas]

On 03/09/2024 17:09, 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 ab21ffadbd Add instructions to edit via POPEditor.com to all 
translated files
ab21ffadbd is described below

commit ab21ffadbdc2b8d8cb8db23758aa74ba786cdf4c
Author: Mark Thomas 
AuthorDate: Tue Sep 3 17:08:09 2024 +0100

 Add instructions to edit via POPEditor.com to all translated files


I haven't run an import with this commit in place yet. I wanted to give 
folks a chance to review the text before it was added to every 
translated file.


Mark


---
  java/org/apache/tomcat/buildutil/translate/Import.java |  1 +
  java/org/apache/tomcat/buildutil/translate/Utils.java  | 11 +++
  2 files changed, 12 insertions(+)

diff --git a/java/org/apache/tomcat/buildutil/translate/Import.java 
b/java/org/apache/tomcat/buildutil/translate/Import.java
index b46a61a622..81ba4431a4 100644
--- a/java/org/apache/tomcat/buildutil/translate/Import.java
+++ b/java/org/apache/tomcat/buildutil/translate/Import.java
@@ -76,6 +76,7 @@ public class Import {
  FileOutputStream fos = new FileOutputStream(outFile);
  w = new OutputStreamWriter(fos, StandardCharsets.UTF_8);
  org.apache.tomcat.buildutil.Utils.insertLicense(w);
+Utils.insertEditInstructions(w);
  }
  
  if (!currentGroup.equals(cKey.group)) {

diff --git a/java/org/apache/tomcat/buildutil/translate/Utils.java 
b/java/org/apache/tomcat/buildutil/translate/Utils.java
index 91b896f9ec..24be38e937 100644
--- a/java/org/apache/tomcat/buildutil/translate/Utils.java
+++ b/java/org/apache/tomcat/buildutil/translate/Utils.java
@@ -201,4 +201,15 @@ public class Utils {
  ioe.printStackTrace();
  }
  }
+
+
+static void insertEditInstructions(Writer w) throws IOException {
+w.write(System.lineSeparator());
+w.write("# Do not edit this file directly. Translations are managed via 
poeditor.");
+w.write(System.lineSeparator());
+w.write("# Join to edit translations: 
https://poeditor.com/join/project/NUTIjDWzrl";);
+w.write(System.lineSeparator());
+w.write("# View the translations: 
https://poeditor.com/projects/view?id=221603";);
+w.write(System.lineSeparator());
+}
  }


-
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

Tagging the September releases and 11.0.x stability

[Mark Thomas]

Hi all,

I'm just wrapping up the fix for BZ 69302. Once that is committed, I 
expect to tag 11.0.0-M25.


I also think we need to start thinking about declaring 11.0.x stable. 
The specs are implemented, the TCKs are passing, 11.0.x is pretty close 
to 10.1.x.


A thought that has been forming is that we could announce the first 
11.0.x stable release at Community Over Code in Denver. If we engage 
with M&P we might even get some press out of it. (And the Apache Tomcat 
project is 25 years old this year.)


Thoughts?

Mark

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

Re: (tomcat) branch 9.0.x updated: Fix imports

[Mark Thomas]

1 Sept 2024 09:22:03 r...@apache.org:


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

remm pushed a commit to branch 9.0.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git


The following commit(s) were added to refs/heads/9.0.x by this push:
 new 9a8848a10d Fix imports
9a8848a10d is described below

commit 9a8848a10d1fb2c166c00372ee2233a7cc252303
Author: remm 
AuthorDate: Sun Sep 1 10:21:50 2024 +0200

    Fix imports


Thanks.

Mark

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

Re: [QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

On 30/08/2024 08:01, Felix Schumacher wrote:


Am 29.08.24 um 18:29 schrieb Mark Thomas:

On 29/08/2024 15:34, Felix Schumacher wrote:



While I don't object to buying a license, I would love to know, which 
diagram you looked at and what exactly did not work out. (the 
activation stuff in mermaid is brittle, but I think I managed to get 
them all right)


I couldn't find a way to get the gap in the activation of Catalina 
between the call to setParentClassLoader() and start(). I see how you 
fixed that. Nice.


There are a couple of places where the message arrows don't quite meet 
up with the activation bar correctly and the await note isn't quite in 
the right place.


I only see one gap at the message await() from Catalina to itself.

The note is a bit better placed, when we use "note right" (or even "note 
left") instead of "note right of Catalina".


To get even more of the original look, we can use UML style, by adding 
"skinparam style strictuml" and to mimic the original drawing even more, 
we can switch off the actors at the bottom, by specifying "hide 
footbox". (full code at the end)


You have convinced me. I did a little more playing around and if I add 
explicit return messages it fixes the incomplete message line and the 
activation bars look better. I can even put the await note exactly where 
I want it :)


I think we switch to PlantUML and keep Visual Paradigm as a fallback option.

Thanks for all your input on this. It has been really helpful.

Mark

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

Re: [QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

On 29/08/2024 17:29, Mark Thomas wrote:

On 29/08/2024 15:34, Felix Schumacher wrote:




Another alternative to use would be umlet (https://www.umlet.com/), 
which I used way back, but haven't looked at lately.


I'll take a look.


The Eclipse plug-in didn't seem to do anything and the online tool is 
very hard work for sequence diagrams - it seems you have to draw every 
bit by hand.


Still leaning towards Visual Paradigm but would be happy to be convinced 
to use one of the tools with human readable input.


Mark

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

Re: [QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

On 29/08/2024 15:34, Felix Schumacher wrote:



While I don't object to buying a license, I would love to know, which 
diagram you looked at and what exactly did not work out. (the activation 
stuff in mermaid is brittle, but I think I managed to get them all right)


I couldn't find a way to get the gap in the activation of Catalina 
between the call to setParentClassLoader() and start(). I see how you 
fixed that. Nice.


There are a couple of places where the message arrows don't quite meet 
up with the activation bar correctly and the await note isn't quite in 
the right place.


and for mermaidjs I got 


I found that very hard to read but I suspect that is a fairly easy fix.

My biggest complaint with mermaidjs was that the text on messages to 
self is centered rather than to the right. That is probably fixable too.


There is a missing activation bar for the digester but that might be due 
to the issues you mentioned.


The label is in the right place for await() which is good.

To summarize my findings. plantuml seemed to be more predictable and 
feature-rich (for sequence diagrams) than mermaidjs. But I didn't see 
any showstoppers with both of them.


Another alternative to use would be umlet (https://www.umlet.com/), 
which I used way back, but haven't looked at lately.


I'll take a look.


I hope you didn't mind the inline code and thus this long message.


Not at all. This is all really useful.

I do really like the idea of the source being human readable but I think 
I am still leaning towards Visual Paradigm because it doesn't have any 
of the niggles in the output and generally, we have a lot more control 
over the final layout.


Another factor is time. While Visual Paradigm also has its quirks, I've 
found I have spent far less time cajoling the tool into providing the 
output I want.


Mark

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

Re: [QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

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

Felix,

On 8/29/24 05:06, Felix Schumacher wrote:



Am 25. August 2024 10:36:44 MESZ schrieb Mark Thomas :

All,

You have probably seen that I am working on updating the UML diagrams 
we have in the architecture section of the Tomcat documentation.


The original diagrams were written in IBM Rational Rose. They were 
donated by a contributor. I don't thnk any committer ever had access 
to a license for IBM Rational Rose. That made maintaining them 
difficult. I managed to find a tool to export them to SVG but they 
are still very out of date.


My expectation is that architecture diagrams like this (and possibly 
a few more) will be required to meet the CRA requirements. Even if 
I'm wrong on that, there are other benefits to having up to date 
diagrams explaining Tomcat's internal structure and how it works such 
as helping new contributors find their way around the code base.


I've found a tool that appears to do everything we need and a lot 
more with a free community edition - Visual Paradigm - that I have 
been using to create updated diagrams. The tool is available for 
Windows, Linux, Mac and has an on-line edition.


To ensure we don't end up in the same position as we did with the 
previous diagrams, I think - as a minimum - we should take copies of 
the installers for the community edition and put them somewhere safe 
- I have access to an ASF owned Google Drive we could use.


The free version does everything that we want but it does watermark 
the output when the diagrams are exported.


I have been wondering about the benefits of purchasing a license. A 
perpetual license for the modeler version (the entry level) would 
cost $99 for a single user. There is a floating license version but 
that requires a license server to be installed. It is designed for 
office LANs rather than global collaboration.


The main benefit of the license is that it means the exported 
diagrams don't contain the watermarks (company logo in top-right 
corner).


If we did want to purchase a license (in the name of the Tomcat PMC) 
we could use the Google security funding since the primary driver for 
this work is the CRA.


Thoughts?

Personally, I am leaning towards spending the $99 so we can remove 
the watermark from the Tomcat docs.


Have you thought about using a tool like plantuml or mermaid-js?

That way the source would be human readable. Plantuml could probably 
be added to the ant setup and would render SVG files or even ASCII art.


The files under architecture looked like sequence diagrams, which 
should be doable.


If other tools are on the menu, there is always graphviz.


I'm happy to look at suggested alternatives.

I've had hit-or-miss results with graphviz. When it's willing to 
generate a nice-looking graph for you, it's fantastic and easy to work 
with.


When you can't get it to generate the graph you WANT, it's a total PITA.


Looking at what is required to generate a class diagram:

https://graphviz.org/Gallery/directed/UML_Class_diagram.html

that looks like too much hand-crafting is required. While PlantUML 
didn't work out, I was able to produce something close within minutes. 
I'm not even sure where I'd need to start with graphviz.


Mark

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

Re: [QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

On 29/08/2024 11:36, Mark Thomas wrote:

On 29/08/2024 10:06, Felix Schumacher wrote:

Am 25. August 2024 10:36:44 MESZ schrieb Mark Thomas :





Thoughts?

Personally, I am leaning towards spending the $99 so we can remove 
the watermark from the Tomcat docs.


Have you thought about using a tool like plantuml or mermaid-js?


I did look for free UML tools but don't recall either of those.

That way the source would be human readable. Plantuml could probably 
be added to the ant setup and would render SVG files or even ASCII art.


I'd like that a lot.

The files under architecture looked like sequence diagrams, which 
should be doable.


Agreed. I'll see if I can re-create diagrams one and two in PlantUML. If 
the output is comparable then we can look at integrating PlantUML into 
the site build.


I'm disappointed to report that I found some issues with displaying 
activation with both options.


mermaid-js seemed to move the messages to make space for the activation 
bar but then didn't display the activation bar. There were also issues 
with message text placement that are probably solvable but I didn't look 
into it.


PlantUML was better but it is opinionated on when you can 
activate/deactivate actors which means I can't recreate the diagrams 
exactly. It may well be right from a strict view of the UML spec - it is 
a *very* long time since I did any UML work in anger - but that 
strictness is a little too constraining.


Given the relatively low cost I still think the Visual Paradigm is the 
better option right now. I'm disappointed as I really like the idea of 
the source being human readable but I think the end result needs to be 
the priority.


Mark

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

Re: [QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

On 29/08/2024 10:06, Felix Schumacher wrote:

Am 25. August 2024 10:36:44 MESZ schrieb Mark Thomas :





Thoughts?

Personally, I am leaning towards spending the $99 so we can remove the 
watermark from the Tomcat docs.


Have you thought about using a tool like plantuml or mermaid-js?


I did look for free UML tools but don't recall either of those.


That way the source would be human readable. Plantuml could probably be added 
to the ant setup and would render SVG files or even ASCII art.


I'd like that a lot.


The files under architecture looked like sequence diagrams, which should be 
doable.


Agreed. I'll see if I can re-create diagrams one and two in PlantUML. If 
the output is comparable then we can look at integrating PlantUML into 
the site build.


Mark

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

Re: svn commit: r1920023 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml

[Mark Thomas]

On 28/08/2024 22:27, Christopher Schultz wrote:

On 8/28/24 06:48, Mark Thomas wrote:




I've restructured the page. I've added the things you suggested. Any 
better?


Yes, I like your work, here. I committed some minor changes. Mostly 
re-wording the "giving the attacker administrative rights before an 
attack is cheating" bit.


I was tempted to edit that page to include that quote. It sums it up 
rather nicely.


I did make a minor addition to clarify that standard distributions were 
from the ASF. I don't think any downstream is adding their own web 
applications but just in case...


I'll ping the security@ folks for a review before we start linking to 
this from the other security pages.


Mark

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

Re: svn commit: r1920023 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml

[Mark Thomas]

On 27/08/2024 17:34, Christopher Schultz wrote:

Mark,

On 8/27/24 11:59, Mark Thomas wrote:

On 26/08/2024 15:18, Christopher Schultz wrote:




+  Data received by an AJP connector is trusted.


Maybe clarify which data you are talking about? I'm guessing that 
"request attributes" and certain headers should be considered 
trusted, but the request entity for example is not.


Thanks. Good catch. I've updated the docs.

Any further changes before I add some links to this page from the 
security docs?


I think:

"
Vulnerabilities in deployed web applications are application 
vulnerabilities, not Tomcat vulnerabilities.

"

...ought to mention that Tomcat-provided web applications are in-scope 
for security vulnerability reports. Manager and host-manager are quite 
important while ROOT, docs, and examples would be limited to e.g. "low 
importance" because they should never be deployed into a production 
environment.


s/multi-cast/multicast/g

This list is sufficiently long that we might want to break it down a 
little into separate sections with separate titles e.g.:


Trusted Environments

The following environments, user, and code are always considered 
trusted. Reports that users with control over these environments will be 
rejected on the basis that those users are in fact trusted and have 
administrative or equivalent access:


* Deployed web applications
* Access via JMX
* Access via Java Attach API or other debugging interfaces
* ...

As I write this, it seems to be falling apart a little. Maybe this 
comment will spark someone else's creativity. But the list seems to be 
getting long and I'm a very strong supporter of "Parallel Structure"[1] 
in writing, and this is all over the place.


I've restructured the page. I've added the things you suggested. Any better?

Mark

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

Re: Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

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

Mark,

On 8/27/24 11:31, Mark Thomas wrote:

On 26/08/2024 15:14, Christopher Schultz wrote:

All,

On 8/16/24 11:25, Mark Thomas wrote:

On 16/08/2024 13:40, Tim Funk wrote:

How about  missingEqualsCookie="allow | ignore"?


The proposed options were:
- ignore
- name
- value


By using [allow | ignore] instead of yes/no, it opens the door to
additional behaviors. (such as reject which triggers a http error)


Agreed.


I think maybe we should couple this new configuration attribute with 
an enabled-by-default Valve (maybe only in 11/12, disabled-by-default 
in 9/10) that detects empty cookie names and throws an exception 
and/or returns a 400 response.


"ignore" should remove the cookie entirely and allow requests 
containing these to be serviced. Using the "value" option with this 
Valve enabled would cause a 400 response.


Or it could be worked-into an existing Valve/Filter such as the 
HttpHeaderSecurityFilter or similar.


Or we could add a "reject" option to the configuration setting that 
triggered an exception.


At what stage would this trigger an exception? Coudl the application 
somehow catch that exception? I would think that a 400 response might 
make more sense because what does "reject" mean to an application when 
Tomcat is doing the rejecting? It wouldn't be much different than 
"ignore" other than you have to tell the client it's being "rejected". 
That suggests a 400 response to me.


Currently, when the cookie header is parsed. If session cookies are 
enabled (they are by default) that parsing will occur during request 
parsing which means any exception would be outside of the control of the 
application and the client would see a 400 response.


If an application wants to control what to do here, it could use the 
name option (or the value option if the Servlet spec is changed to allow 
cookies with no name) and then check the cookies itself at an 
appropriate point.


I don't think it is worth trying to refactor the cookie parsing so an 
exception is thrown when the application requests the cookies.


Mark

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

Re: [QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

On 26/08/2024 15:41, Christopher Schultz wrote:



Personally, I am leaning towards spending the $99 so we can remove the 
watermark from the Tomcat docs.


1. $99 is nothing, even if it ends up being tied to a single person.


I've been thinking about this some more and I'd prefer the floating 
license since that is what we really want - so anyone on the PMC can use 
it. There might be a few hoops to jump through to use it but I think it 
is worth it to ensure we can edit these docs going forward.


That is $129. Which is still not very much.


2. Maybe they would give ASF one of more licenses at no charge?


I suspect not. They have a free non-commercial edition. It just adds the 
watermark.


I wouldn't want to put the burden of updating all diagrams on just one 
committer, even if you are kind of volunteering, here.


Hence my leaning more towards the floating option. While I am happy to 
do this now, should someone else need to update these diagrams a few 
years down the line I'd like everything they need to do that to be in 
the PMC private repo.


There is no great rush here but I'd like to get this sorted while it is 
top of mind. Therefore, I plan to purchase 1 floating license for the 
Tomcat PMC with the Google funding early next week unless there are 
objections.


Mark

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

Re: svn commit: r1920023 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml

[Mark Thomas]

On 26/08/2024 15:18, Christopher Schultz wrote:




+  Data received by an AJP connector is trusted.


Maybe clarify which data you are talking about? I'm guessing that 
"request attributes" and certain headers should be considered trusted, 
but the request entity for example is not.


Thanks. Good catch. I've updated the docs.

Any further changes before I add some links to this page from the 
security docs?


Mark

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

Re: Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

On 26/08/2024 14:58, Christopher Schultz wrote:

What good is a cookie with no name?


I'm not sure. I know we had some users that wanted a cookie without a 
value (I guess it is some sort of boolean flag). That makes more sense 
to me than a cookie without a name.


Is this one of those "optimizations" where an application has only one 
cookie and doesn't want to waste all those bytes on a pesky cookie _name_?


I haven't yet found (or thought of) a use case for this behaviour.

The place to start researching is probably:
https://github.com/httpwg/http-extensions/issues/159

I haven't read all the links yet.

Mark

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

Re: Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

On 26/08/2024 15:09, Christopher Schultz wrote:

Mark,

On 8/16/24 04:32, Mark Thomas wrote:

On 14/08/2024 19:12, Konstantin Kolinko wrote:




I think that
1) We would better switch to "ignore" mode right now, in all 
supported versions.


Based on past experience I am extremely hesitant to change anything 
related to cookie handling behaviour unless we have to. I'd prefer to 
use "name" as the default more for 9.0.x and 10.1.x.


I'm prepared to be convinced otherwise though.



2) The "empty name" option seems to be the correct behaviour,
But as the majority of web applications would not need this feature,
I think that\ "ignore" would better remain the default behaviour.


No objections to that.

I'm going to start working on this "noEqualsCookie" option. 
Suggestions for a better name still welcome.


cookiesWithoutEquals?


That sounds better to me too. Thanks. We haven't had any releases so I 
can easily do a rename. Unless there are objections, I'll do this tomorrow.


Mark

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

Re: Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

On 26/08/2024 15:14, Christopher Schultz wrote:

All,

On 8/16/24 11:25, Mark Thomas wrote:

On 16/08/2024 13:40, Tim Funk wrote:

How about  missingEqualsCookie="allow | ignore"?


The proposed options were:
- ignore
- name
- value


By using [allow | ignore] instead of yes/no, it opens the door to
additional behaviors. (such as reject which triggers a http error)


Agreed.


I think maybe we should couple this new configuration attribute with an 
enabled-by-default Valve (maybe only in 11/12, disabled-by-default in 
9/10) that detects empty cookie names and throws an exception and/or 
returns a 400 response.


"ignore" should remove the cookie entirely and allow requests containing 
these to be serviced. Using the "value" option with this Valve enabled 
would cause a 400 response.


Or it could be worked-into an existing Valve/Filter such as the 
HttpHeaderSecurityFilter or similar.


Or we could add a "reject" option to the configuration setting that 
triggered an exception.


Mark

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

Re: Create a Tomcat 12 branch?

[Mark Thomas]

26 Aug 2024 14:50:23 Christopher Schultz :

Is there anything in Jakarta EE 12 that would actually be 
_inappropriate_ for us to put into Tomcat 11?


It is very early days for Jakarta EE 12. The release of 11 is still in 
progress (but is complete for the specifications Tomcat implements).


Generally, I think anything that is new is probably safe to back port but 
we'll need to look at it all on a case by case basis.


We can't change any of the Jakarta APIs in 11 so that may mean a little 
more hope jumping for folks that want to use features that require new 
API like early hints.


I am very wary of backporting changes to anything cookie related as past 
experience shows changes to cookie behaviour in stable versions always 
breaks something for someone.


I've been thinking about the EL language changes. The changes so far 
could be put behind an option to enable them in Tomcat 11. If we went 
that way I'd want to see if there was a way to do that that didn't use a 
system property.


Mark

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

[QUESTION] Purchase UML tool using Google security funding

[Mark Thomas]

All,

You have probably seen that I am working on updating the UML diagrams we 
have in the architecture section of the Tomcat documentation.


The original diagrams were written in IBM Rational Rose. They were 
donated by a contributor. I don't thnk any committer ever had access to 
a license for IBM Rational Rose. That made maintaining them difficult. I 
managed to find a tool to export them to SVG but they are still very out 
of date.


My expectation is that architecture diagrams like this (and possibly a 
few more) will be required to meet the CRA requirements. Even if I'm 
wrong on that, there are other benefits to having up to date diagrams 
explaining Tomcat's internal structure and how it works such as helping 
new contributors find their way around the code base.


I've found a tool that appears to do everything we need and a lot more 
with a free community edition - Visual Paradigm - that I have been using 
to create updated diagrams. The tool is available for Windows, Linux, 
Mac and has an on-line edition.


To ensure we don't end up in the same position as we did with the 
previous diagrams, I think - as a minimum - we should take copies of the 
installers for the community edition and put them somewhere safe - I 
have access to an ASF owned Google Drive we could use.


The free version does everything that we want but it does watermark the 
output when the diagrams are exported.


I have been wondering about the benefits of purchasing a license. A 
perpetual license for the modeler version (the entry level) would cost 
$99 for a single user. There is a floating license version but that 
requires a license server to be installed. It is designed for office 
LANs rather than global collaboration.


The main benefit of the license is that it means the exported diagrams 
don't contain the watermarks (company logo in top-right corner).


If we did want to purchase a license (in the name of the Tomcat PMC) we 
could use the Google security funding since the primary driver for this 
work is the CRA.


Thoughts?

Personally, I am leaning towards spending the $99 so we can remove the 
watermark from the Tomcat docs.


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: Expected behaviour has been clarified when writing >= c-l bytes to body

[Mark Thomas]

23 Aug 2024 14:34:07 Rémy Maucherat :


On Thu, Aug 22, 2024 at 2:33 PM  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 69eff83577 Expected behaviour has been clarified when writing 
>= c-l bytes to body

69eff83577 is described below

commit 69eff83577f7c00cbaaca9384ab4b1989f516797
Author: Mark Thomas 
AuthorDate: Thu Aug 22 13:33:10 2024 +0100

    Expected behaviour has been clarified when writing >= c-l bytes to 
body


I'm not sure yet whether this is a good idea. Usually we want to keep
things open for further processing.

Maybe we should be doing it using the suspended flag instead and in the 
facades.


Ack. I had a similar concern. That is the main reason I didn't back-port 
it. However, the TCK for 6.1 has been updated to explicitly check for an 
exception in this case. The update 6.1 TCK hasn't been released yet but 
when it has we'll need this change to pass.


We could try pushing back on the TCK change but it is testing language 
that has been in the specification for a long time.


FYI the specification for 6.2 is going to clarify a bunch of edge cases 
around this such as expected behaviour when writing > content-length 
bytes in a single write.


Mark




Rémy


---
.../catalina/connector/LocalStrings.properties |  1 +
.../apache/catalina/connector/OutputBuffer.java    | 30 ++---
.../catalina/connector/TestCoyoteOutputStream.java | 50 
++

3 files changed, 76 insertions(+), 5 deletions(-)

diff --git 
a/java/org/apache/catalina/connector/LocalStrings.properties 
b/java/org/apache/catalina/connector/LocalStrings.properties

index 077cf46136..d20cd26bc4 100644
--- a/java/org/apache/catalina/connector/LocalStrings.properties
+++ b/java/org/apache/catalina/connector/LocalStrings.properties
@@ -83,6 +83,7 @@ coyoteResponse.setBufferSize.ise=Cannot change 
buffer size after data has been w

inputBuffer.requiresNonBlocking=Not available in non blocking mode
inputBuffer.streamClosed=Stream closed

+outputBuffer.closed=The response may not be written to once it has 
been closed
outputBuffer.writeNull=The String argument to write(String,int,int) 
may not be null


request.asyncNotSupported=A filter or servlet of the current chain 
does not support asynchronous operations.
diff --git a/java/org/apache/catalina/connector/OutputBuffer.java 
b/java/org/apache/catalina/connector/OutputBuffer.java

index b185561ef3..04cf82e632 100644
--- a/java/org/apache/catalina/connector/OutputBuffer.java
+++ b/java/org/apache/catalina/connector/OutputBuffer.java
@@ -358,11 +358,11 @@ public class OutputBuffer extends Writer {
 private void writeBytes(byte b[], int off, int len) throws 
IOException {


 if (closed) {
-    return;
+    throw new 
IOException(sm.getString("outputBuffer.closed"));

 }

 append(b, off, len);
-    bytesWritten += len;
+    updateBytesWritten(len);

 // if called from within flush(), then immediately flush
 // remaining bytes
@@ -376,12 +376,12 @@ public class OutputBuffer extends Writer {
 private void writeBytes(ByteBuffer from) throws IOException {

 if (closed) {
-    return;
+    throw new 
IOException(sm.getString("outputBuffer.closed"));

 }

 int remaining = from.remaining();
 append(from);
-    bytesWritten += remaining;
+    updateBytesWritten(remaining);

 // if called from within flush(), then immediately flush
 // remaining bytes
@@ -394,6 +394,10 @@ public class OutputBuffer extends Writer {

 public void writeByte(int b) throws IOException {

+    if (closed) {
+    throw new 
IOException(sm.getString("outputBuffer.closed"));

+    }
+
 if (suspended) {
 return;
 }
@@ -403,8 +407,24 @@ public class OutputBuffer extends Writer {
 }

 transfer((byte) b, bb);
-    bytesWritten++;
+    updateBytesWritten(1);
+    }
+

+    private void updateBytesWritten(int increment) throws IOException 
{

+    bytesWritten += increment;
+    int contentLength = coyoteResponse.getContentLength();
+
+    /*
+ * Handle the requirements of section 5.7 of the Servlet 
specification - Closure of the Response Object.

+ *
+ * Currently this just handles the simple case. There is work 
in progress to better define what should happen if
+ * an attempt is made to write > content-length bytes. When 
that work is complete, this is likely where the

+ * implementation will end up.
+ */
+    if (contentLength != -1 && bytesWritten >= contentLength) {
+    close();
+    }
 }


diff --git 
a/test/org/apache/c

Re: Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

On 19/08/2024 08:38, Rémy Maucherat wrote:

On Fri, Aug 16, 2024 at 5:25 PM Mark Thomas  wrote:


On 16/08/2024 13:40, Tim Funk wrote:

How about  missingEqualsCookie="allow | ignore"?


The proposed options were:
- ignore
- name
- value


Ok, I think your proposed options are very good. Thanks for the
summary. Personally I would have interpreted these as name rather than
value, so it helped clarify.

I also think you are right about not changing the behavior for current
branches. It could be changed to ignore already in 11, and we could
see if people start complaining ?


I've started working on this and found a problem.

The Javadoc for jakarta.servlet.http.Cookie says (and effectively the 
same restriction exists all the way back to Servlet 2.1) that Cookie 
names cannot be the zero length string.


This is going to need to change at the Servlet spec level. That means 
only Tomcat 12 can possibly support the "value" option.


If we want to change the default in 11 then we can go ahead with 
"ignore" and "name" and potentially add "value" as as option in Tomcat 
12 if the Servlet spec group agrees to the change.


Given how edge case this is, I'm not sure what the Servlet spec will do.

Mark

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

Re: svn commit: r1920023 - in /tomcat/site/trunk: docs/security-model.html xdocs/security-model.xml

[Mark Thomas]

On 19/08/2024 12:23, ma...@apache.org wrote:

Author: markt
Date: Mon Aug 19 11:23:05 2024
New Revision: 1920023

URL: http://svn.apache.org/viewvc?rev=1920023&view=rev
Log:
Add first draft of security model


All,

This is an attempt to document something I think we all instinctively 
understand. It is likely that we'll need this, or something like it, to 
meet the CRA requirements (or to be more accurate for our downstream 
users to meet their CRA requirements).


It is currently not linked from the rest of the Tomcat site. My thinking 
was we'd refine it and then link it once we were happy with it.


Feel free to update/comment/etc just like any other site content.

Mark

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

Re: Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

On 16/08/2024 13:40, Tim Funk wrote:

How about  missingEqualsCookie="allow | ignore"?


The proposed options were:
- ignore
- name
- value


By using [allow | ignore] instead of yes/no, it opens the door to
additional behaviors. (such as reject which triggers a http error)


Agreed.

Mark

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

Re: Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

On 14/08/2024 19:12, Konstantin Kolinko wrote:




I think that
1) We would better switch to "ignore" mode right now, in all supported versions.


Based on past experience I am extremely hesitant to change anything 
related to cookie handling behaviour unless we have to. I'd prefer to 
use "name" as the default more for 9.0.x and 10.1.x.


I'm prepared to be convinced otherwise though.



2) The "empty name" option seems to be the correct behaviour,
But as the majority of web applications would not need this feature,
I think that\ "ignore" would better remain the default behaviour.


No objections to that.

I'm going to start working on this "noEqualsCookie" option. Suggestions 
for a better name still welcome.


Mark

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

Cookie parsing and upcoming updates to RFC6265

[Mark Thomas]

Hi all,

The IETF HTTP working group is working on RFC 6265bis (the RFC that will 
replace RFC 6265). I have been reviewing the changes to see what impact 
they might have on Tomcat and our users.


There are a few changes (e.g. SameSite) we have already implemented.

There are quite a few changes that I think don't impact us.

And then there is this:

Cookie: apple

Current Tomcat interprets that as name="apple" value=""

RFC 6265 says any name-value-pair from a Set-Cookie string without an 
"=" should be ignored and the Cookie headers should always use = between 
the name and the value.


RFC 6265bis would required name="", value="apple" when using the relaxed 
(receiver) parsing. The strict (sender) syntax does not allow a cookie 
without a name.


RFC 6265bis does appear to be consistent with browser intention [1] (at 
least intentions 10 years ago anyway).


So we are currently:
- accepting a cookie RFC 6265 says we should ignore
- interpreting it the opposite way to apparent browser intention
- interpreting it the opposite way to likely RFC 6265bis requirements

Given the above, I do wonder to what extent applications are actually 
using these cookies.


So, what should we do?

I think we need a new configuration option named "noEqualsCookie" 
(suggestions for a better name welcome) with three options:

- ignore
- name
- value

Tomcat 9, 10 & 11 have the default set to name so there is no change.

Tomcat 12 has the default set to value.

Thoughts?

Mark


[1] https://lists.apache.org/thread/w2ovto22r4mbvh0o307fvljvbkfsvzb4

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

[ANN] Apache Tomcat Connectors 1.2.50 released

[Mark Thomas]

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


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

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

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

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

Thank you,
--
The Apache Tomcat Team

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

[VOTE][RESULT] Release Apache Tomcat Connectors (JK) 1.2.50

[Mark Thomas]

The following votes were cast:

Binding:
+1: markt, schultz, rjung

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

Create a Tomcat 12 branch?

[Mark Thomas]

All,

As I mentioned earlier, I am starting work on some new EL API features 
that will be part of Jakarta EE 12 so implemented in Tomcat 12.


How do we want to handle this?

My current thinking is:

- create a 11.0.x branch from current main
- main becomes 12.0.x

I'm not expecting releases to start from 12.0.x any time soon. Users 
that want to experiment with the new features can use snapshots. If we 
reach a point where snapshots would be useful we can re-assess.


The other alternative I thought of was creating my own 12.0.x branch in 
my fork but that seems wrong.


Yes, it means a little more back-porting but (for me at least) that is 
all scripted and I'm not expecting many conflicts between 12.0.x and 11.0.x.


I'd update the CI systems to build 12.0.x.

Part of me thinks it is a little odd to be thinking about 12.0.x before 
11.0.x is stable but on reflection I think it is a good thing that there 
is momentum already for new features in Jakarta EE 12.


Oh, there is also a small change to the Servlet API we could pick up.

Thoughts?

Mark

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

Re: (tomcat) 02/02: Regenerate with latest JavaCC (7.0.13)

[Mark Thomas]

On 12/08/2024 13:51, 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

commit 46f2b6bbf6cae325ec2bce2c74740c627adf169e
Author: Mark Thomas 
AuthorDate: Mon Aug 12 13:46:01 2024 +0100

 Regenerate with latest JavaCC (7.0.13)
 
 No change.


FYI I'm starting to look at some possible EL changes for Tomcat 12 (yes, 
I know - 11 isn't stable and I'm looking at 12) so I wanted to make sure 
I started from the current latest generated code.


We don't need to backport this since the generated code is the same but 
I am going to back-port for consistency.


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 Connectors (JK) 1.2.50

[Mark Thomas]

On 09/08/2024 02:08, Rainer Jung wrote:

Am 08.08.24 um 16:13 schrieb Mark Thomas:

Tag:
https://github.com/apache/tomcat-connectors/tree/JK_1_2_50

Source:
https://github.com/apache/tomcat-connectors/tree/JK_1_2_50

Dist:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/jk/


This is a maintenance release with a handful of dependency updates and 
bug fixes (compared to 1.2.49). It also includes Windows binaries for 
IIS.


The significant changes are:
- Improve shared memory handling on non-Windows

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


I still need to do some more checks but currently looks good except for 
the binary zip files: for 1.2.49 they contained LICENSE and NOTICE, for 
1.2.50 these are missing from the binaries zip files. Maybe there is an 
easy way to add them and redo the sha512 and gpg signature.


I figured out what I did wrong. I built the binaries from the source 
bundle rather than a checkout. The paths are slightly different and the 
scripts are configured for the checkout.


I've updated the zips and regenerated the hashes and signatures. The 
actual binaries remain unchanged.


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 Connectors (JK) 1.2.50

[Mark Thomas]

On 08/08/2024 15:13, Mark Thomas wrote:

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


Compiles on Ubuntu 22.04 (fully patched) and passes a simple smoke test 
with httpd.


Windows binary for 64-bit passes a simple smoke test on:
- Windows 2022
- Windows 2012
- Windows 11

Mark

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

[VOTE] Release Apache Tomcat Connectors (JK) 1.2.50

[Mark Thomas]

Tag:
https://github.com/apache/tomcat-connectors/tree/JK_1_2_50

Source:
https://github.com/apache/tomcat-connectors/tree/JK_1_2_50

Dist:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/jk/


This is a maintenance release with a handful of dependency updates and 
bug fixes (compared to 1.2.49). It also includes Windows binaries for IIS.


The significant changes are:
- Improve shared memory handling on non-Windows

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

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

Re: (tomcat) branch main updated (5aa3aaf72d -> 3e80377f3b)

[Mark Thomas]

On 07/08/2024 17:23, ma...@apache.org wrote:

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

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


 from 5aa3aaf72d Fix link
  new 248827a857 Add trace logging for receipt of WebSocket session close 
message
  new 310905447c If a blocking message write times out, don't write again 
before throwing
  new 3e80377f3b Encoding error on send should not automatically close the 
connection


These changes, particularly the third, should hopefully address the 
intermittent test failures we have been seeing for the WebSocket TCK in 
the tomcat-tck repo.


Mark

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

Re: TLD scanner and debug logging

[Mark Thomas]

On 06/08/2024 10:50, Konstantin Kolinko wrote:

вт, 6 авг. 2024 г. в 12:44, Mark Thomas :





I'll get those changes done.


+1

Looking at other usages of JarScannerCallback, e.g.
o.a.catalina.startup.ContextConfig, I see no obvious problem. There is
one message about DEBUG level (contextConfig.sci.info) but it is about
a different situation (whether a stacktrace is being printed), and it
is OK - it uses log.debug() there.


Update the documentation?
https://tomcat.apache.org/tomcat-11.0-doc/logging.html

a) It already mentions the "ALL" level. - OK

quote: "To enable debug logging for part of Tomcat's internals, you
should configure both the appropriate logger(s) and the appropriate
handler(s) to use the FINEST or ALL level. e.g.: "

b) There are two configuration samples (a global one, and one for the
examples web application),

quote: "Example logging.properties file to be placed in $CATALINA_BASE/conf: "

- Update to s/FINE/ALL/.
- The sample uses a FileHandler, but we are using AsyncFileHandler nowadays.

quote: "Example logging.properties for the servlet-examples web
application to be placed in WEB-INF/classes inside the web
application"

- The same as above
- ConsoleHandler  is missing the ".encoding" setting.

c) BTW, in "Considerations for production usage" it says
quote: "The handlers by default use the system default encoding to
write the log files. It can be configured with encoding property. See
Javadoc for details."

I think it is still true (as it actually talks about programmed defaults),
but our default configuration has been configured to use "*.encoding =
UTF-8" on all handlers, including the ConsoleHandler.

(At the time when that phrase was written, ConsoleHandler was
configured with the system encoding.)


Thanks for the review. I've updated the docs.

Mark

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

Re: TLD scanner and debug logging

[Mark Thomas]

On 06/08/2024 09:56, Rémy Maucherat wrote:

On Tue, Aug 6, 2024 at 10:19 AM Mark Thomas  wrote:


The current TLD scanner logs the following message if JARs are scanned
but not TLDs are found:


At least one JAR was scanned for TLDs yet contained no TLDs. Enable
debug logging for this logger for a complete list of JARs that were
scanned but no TLDs were found in them. Skipping unneeded JARs during
scanning can improve startup time and JSP compilation time.


However, the detailed log messages are now logged at trace level. This
creates a couple of issues:

1. The message above is incorrect

2. With the message above corrected, and the correct logger level set,
the messages still are not displayed because the logger handlers are
configured to drop all messages below DEBUG level.


I'd like to propose the following changes:

- Change the default handler level to ALL. This should not change the
current log output but should ensure messages are not dropped if a
logger is explicitly configured to output trace (FINEST) messages.

- Change the message above to say "Enable trace logging..."


The only issue is that all the translations would need to be updated. I
can mark them as fuzzy in POEditor which should mean they get flagged
for review/update but whether anyone will update them is a different
question. The alternative is to switch the TLDScanner back to logging at
debug level.

Thoughts?


So I downgraded these because they did not really look like debug to
me, but more like traces. The separation between the two is quite
subtle ;) Sorry for the trouble ...


No worries.


So instead of doing too much for this, and since this log is likely
useful, I would upgrade back the noTldInJar to debug since most likely
admin action is needed.


OK. That is a much simpler solution.


Otherwise +1 for the idea of enabling ALL by default, there would be
less fiddling around when trying to enable trace.


Exactly.

I'll get those changes done.

Mark

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

[Mark Thomas]

On 02/08/2024 15:15, Mark Thomas wrote:


The proposed 11.0.0-M24 release is:
[ ] -1 Broken - do not release
[ ] +1 Beta   - go ahead and release as 11.0.0-M24


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

TLD scanner and debug logging

[Mark Thomas]

The current TLD scanner logs the following message if JARs are scanned 
but not TLDs are found:



At least one JAR was scanned for TLDs yet contained no TLDs. Enable 
debug logging for this logger for a complete list of JARs that were 
scanned but no TLDs were found in them. Skipping unneeded JARs during 
scanning can improve startup time and JSP compilation time.



However, the detailed log messages are now logged at trace level. This 
creates a couple of issues:


1. The message above is incorrect

2. With the message above corrected, and the correct logger level set, 
the messages still are not displayed because the logger handlers are 
configured to drop all messages below DEBUG level.



I'd like to propose the following changes:

- Change the default handler level to ALL. This should not change the
  current log output but should ensure messages are not dropped if a
  logger is explicitly configured to output trace (FINEST) messages.

- Change the message above to say "Enable trace logging..."


The only issue is that all the translations would need to be updated. I 
can mark them as fuzzy in POEditor which should mean they get flagged 
for review/update but whether anyone will update them is a different 
question. The alternative is to switch the TLDScanner back to logging at 
debug level.


Thoughts?

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

[Mark Thomas]

On 03/08/2024 00:02, Rémy Maucherat wrote:


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


Tests pass on:
- Windows (Tomcat Native 1.3.1 / OpenSSL 3.0.14, FFM tests skipped)
- Linux (Tomcat Native 1.3.1 / OpenSSL Ubuntu 22.04 LTS latest)
- MacOS (Intel, Tomcat Native 1.3.1 / OpenSSL 3.3.1 - homebrew)
- MacOS (M1, Tomcat Native 1.3.1 / OpenSSL 3.3.1 - homebrew)

Build is cross-platform binary reproducible (Linux/Windows).


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

[Mark Thomas]

On 02/08/2024 18:27, Christopher Schultz wrote:


Please reply with a +1 for release or +0/-0/-1 with an explanation.


+1

Tests pass on:
- Windows (Tomcat Native 2.0.8 / OpenSSL 3.0.14, FFM tests skipped)
- Linux (Tomcat Native 2.0.8 / OpenSSL Ubuntu 22.04 LTS latest)
- MacOS (Intel, Tomcat Native 2.0.8 / OpenSSL 3.3.1 - homebrew)
- MacOS (M1, Tomcat Native 2.0.8 / OpenSSL 3.3.1 - homebrew)

Build is cross-platform reproducible (MacOS/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-M24

[Mark Thomas]

On 02/08/2024 15:15, Mark Thomas wrote:

The proposed 11.0.0-M24 release is:
[ ] -1 Broken - do not release
[ ] +1 Beta   - go ahead and release as 11.0.0-M24


Tests pass on:
- Windows (Tomcat Native 2.0.8 / OpenSSL 3.0.14, FFM tests skipped)
- Linux (Tomcat Native 2.0.8 / OpenSSL Ubuntu 22.04 LTS latest)
- MacOS (Intel, Tomcat Native 2.0.8 / OpenSSL 3.3.1 - homebrew)
- MacOS (M1, Tomcat Native 2.0.8 / OpenSSL 3.3.1 - homebrew)

Build is cross-platform (Windows/Linux) repeatable.

Mark

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

Re: New contributor please welcome

[Mark Thomas]

4 Aug 2024 08:19:37 Koteswara Rao Gundapaneni 
:



Hi Team,


I am the best contributor in tomcat dev

How do we say if we run the tomcat through script not a batch file

Regards
Gundapaneni


Address unsubscribed and added to deny lists.

Mark

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

[VOTE] Release Apache Tomcat 11.0.0-M24

[Mark Thomas]

The proposed Apache Tomcat 11.0.0-M24 release is now available for
voting.

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


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

- Add FFM compatibility methods for LibreSSL and BoringSSL support.

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

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-M24/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1507

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M24
5301df36454fcf22081108e25199f29904cadc79

The proposed 11.0.0-M24 release is:
[ ] -1 Broken - do not release
[ ] +1 Beta   - go ahead and release as 11.0.0-M24

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

Re: Sporadic http2 test failures

[Mark Thomas]

On 02/08/2024 12:06, Rainer Jung wrote:

Am 02.08.24 um 10:58 schrieb Mark Thomas:

On 02/08/2024 07:58, Mark Thomas wrote:

On 01/08/2024 23:48, Rainer Jung wrote:



I did not check each occurrence but here are examples which all also 
have a NullPointer in the access log. I don't know whether that 
triggers the failure or is just another symptom triggered by the 
same root cause.




Rainer,

Thanks for the work you have put into this.

The combination of NPE and the timing of these emerging makes me 
think the change to recycle the request and response may be the cause.


I'm holding off closing the 11.0.x vote while I look into this.


I can confirm the request/response recycling for HTTP/2 triggered 
this. Reviewing the code with fresh eyes I see multiple issues. I'll 
have fixes ready shortly but I am going to cancel the 11.0.0-M23 
release vote. I am also going to change my vote to -1 for 10.1.27 and 
9.0.92.


Thanks for investigating so quickly and thoroughly!

Unfortunately my testing zoo always needs a few days before test results 
become reliable enough, so it is hard for me to report very quickly 
after the start of the vote.


No problem. It is my fault for not spotting the problem when I was doing 
the recycling changes.


The 11.0.x tests look good. I am going to back port now.

Mark

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

Re: Sporadic http2 test failures

[Mark Thomas]

On 02/08/2024 09:58, Mark Thomas wrote:

On 02/08/2024 07:58, Mark Thomas wrote:

On 01/08/2024 23:48, Rainer Jung wrote:



I did not check each occurrence but here are examples which all also 
have a NullPointer in the access log. I don't know whether that 
triggers the failure or is just another symptom triggered by the same 
root cause.




Rainer,

Thanks for the work you have put into this.

The combination of NPE and the timing of these emerging makes me think 
the change to recycle the request and response may be the cause.


I'm holding off closing the 11.0.x vote while I look into this.


I can confirm the request/response recycling for HTTP/2 triggered this. 
Reviewing the code with fresh eyes I see multiple issues. I'll have 
fixes ready shortly but I am going to cancel the 11.0.0-M23 release 
vote. I am also going to change my vote to -1 for 10.1.27 and 9.0.92.


I believe I have fixed these issues. I am just running tests on the full 
set of platforms as a check. If they all pass I'll do the back port.


Mark

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

[VOTE][CANCELLED] Release Apache Tomcat 11.0.0-M23

[Mark Thomas]

Hi all,

I am cancelling this release due to multiple regressions introduced by 
the additional of recycling of requests and responses for HTTP/2.


Mark


On 29/07/2024 19:26, Mark Thomas wrote:

The proposed Apache Tomcat 11.0.0-M23 release is now available for
voting.

Apache Tomcat 11.0.0-M23 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:


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

- Add FFM compatibility methods for LibreSSL and BoringSSL support.

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

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-M23/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1504

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M23
2bf2c6a691ad9f2cf68363123419909cebbb308a

The proposed 11.0.0-M23 release is:
[ ] -1 Broken - do not release
[ ] +1 Beta   - go ahead and release as 11.0.0-M23

-
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: Sporadic http2 test failures

[Mark Thomas]

On 02/08/2024 07:58, Mark Thomas wrote:

On 01/08/2024 23:48, Rainer Jung wrote:



I did not check each occurrence but here are examples which all also 
have a NullPointer in the access log. I don't know whether that 
triggers the failure or is just another symptom triggered by the same 
root cause.




Rainer,

Thanks for the work you have put into this.

The combination of NPE and the timing of these emerging makes me think 
the change to recycle the request and response may be the cause.


I'm holding off closing the 11.0.x vote while I look into this.


I can confirm the request/response recycling for HTTP/2 triggered this. 
Reviewing the code with fresh eyes I see multiple issues. I'll have 
fixes ready shortly but I am going to cancel the 11.0.0-M23 release 
vote. I am also going to change my vote to -1 for 10.1.27 and 9.0.92.


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

[Mark Thomas]

I am changing my vote for this release to -1 due to regressions caused 
by the introduction of request and response recycling for HTTP/2.


Mark



On 30/07/2024 20:08, Mark Thomas wrote:

On 30/07/2024 04:32, Rémy Maucherat wrote:


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


Test pass on Linux with Tomcat Native 1.3.1 and OpenSSL 3.0.2 (latest 
Ubuntu 22.04).


Test pass on Windows with Tomcat Native 1.3.1 and OpenSSL 3.0.14 (FFM 
tests skipped)


Test pass on MacOS (Intel & M1) except FFM tests that are expected to 
fail with LibreSSL.


Build is not cross-platform reproducible (build.xml fix in progress).

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

[Mark Thomas]

I am changing my vote for this release to -1 due to regressions caused 
by the introduction of request and response recycling for HTTP/2.


Mark



On 01/08/2024 16:02, Mark Thomas wrote:

On 30/07/2024 16:56, Christopher Schultz wrote:

Please reply with a +1 for release or +0/-0/-1 with an explanation.


+1

Tests pass on Linux with Java 22, Tomcat Native 2.0.8 and current 
OpenSSL from Ubuntu.


Tests pass on Windows with Java 22, Tomcat Native 2.0.8 and OpenSSL 
3.0.14. FFM tests were skipped.


Tests pass on MacOS (M1) with Java 22, Tomcat Native 2.0.8, OpenSSL 
3.3.1 from homebrew and a small modification to build.xml from trunk to 
enable the FFM tests.


Tests pass on MacOS (Inet) with Java 22, Tomcat Native 2.0.8, OpenSSL 
3.3.1 from homebrew and a small modification to build.xml from trunk to 
enable the FFM tests. I did see issues with the tests that use rely on 
multicast but that appears to be an environmental issue after the latest 
OS update. I'm still investigating that.


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 11.0.0-M23

[Mark Thomas]

I am changing my vote for this release to -1 due to regressions caused 
by the introduction of request and response recycling for HTTP/2.


Mark


On 29/07/2024 19:29, Mark Thomas wrote:

On 29/07/2024 19:26, Mark Thomas wrote:


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


Tests pass fully on Linux with Tomcat Native 2.0.8 and OpenSSL 3.0.14.

Tests pass on MacOS (Intel and M1) apart from some FFM tests where 
renegotiation is not supported. If forced to run those tests with 
OpenSSL 3.3.1, those tests pass.


Tests pass on Windows apart from FFM tests which are skipped.

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: Sporadic http2 test failures

[Mark Thomas]

On 01/08/2024 23:48, Rainer Jung wrote:



I did not check each occurrence but here are examples which all also 
have a NullPointer in the access log. I don't know whether that triggers 
the failure or is just another symptom triggered by the same root cause.




Rainer,

Thanks for the work you have put into this.

The combination of NPE and the timing of these emerging makes me think 
the change to recycle the request and response may be the cause.


I'm holding off closing the 11.0.x vote while I look into this.

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

[Mark Thomas]

On 01/08/2024 16:02, Mark Thomas wrote:

On 30/07/2024 16:56, Christopher Schultz wrote:

Please reply with a +1 for release or +0/-0/-1 with an explanation.


+1

Tests pass on Linux with Java 22, Tomcat Native 2.0.8 and current 
OpenSSL from Ubuntu.


Tests pass on Windows with Java 22, Tomcat Native 2.0.8 and OpenSSL 
3.0.14. FFM tests were skipped.


Tests pass on MacOS (M1) with Java 22, Tomcat Native 2.0.8, OpenSSL 
3.3.1 from homebrew and a small modification to build.xml from trunk to 
enable the FFM tests.


Tests pass on MacOS (Inet) with Java 22, Tomcat Native 2.0.8, OpenSSL 
3.3.1 from homebrew and a small modification to build.xml from trunk to 
enable the FFM tests. I did see issues with the tests that use rely on 
multicast but that appears to be an environmental issue after the latest 
OS update. I'm still investigating that.


Solved. Not a Tomcat issue.

One of the security products $dayjob installed on the Mac was getting in 
the way. Once I (re-)disabled (it has a habit of starting up again 
without warning after being disabled) all was well.


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

[Mark Thomas]

On 30/07/2024 16:56, Christopher Schultz wrote:

Please reply with a +1 for release or +0/-0/-1 with an explanation.


+1

Tests pass on Linux with Java 22, Tomcat Native 2.0.8 and current 
OpenSSL from Ubuntu.


Tests pass on Windows with Java 22, Tomcat Native 2.0.8 and OpenSSL 
3.0.14. FFM tests were skipped.


Tests pass on MacOS (M1) with Java 22, Tomcat Native 2.0.8, OpenSSL 
3.3.1 from homebrew and a small modification to build.xml from trunk to 
enable the FFM tests.


Tests pass on MacOS (Inet) with Java 22, Tomcat Native 2.0.8, OpenSSL 
3.3.1 from homebrew and a small modification to build.xml from trunk to 
enable the FFM tests. I did see issues with the tests that use rely on 
multicast but that appears to be an environmental issue after the latest 
OS update. I'm still investigating that.


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

[Mark Thomas]

On 30/07/2024 04:32, Rémy Maucherat wrote:


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


Test pass on Linux with Tomcat Native 1.3.1 and OpenSSL 3.0.2 (latest 
Ubuntu 22.04).


Test pass on Windows with Tomcat Native 1.3.1 and OpenSSL 3.0.14 (FFM 
tests skipped)


Test pass on MacOS (Intel & M1) except FFM tests that are expected to 
fail with LibreSSL.


Build is not cross-platform reproducible (build.xml fix in progress).

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

[Mark Thomas]

On 30/07/2024 04:24, Rémy Maucherat wrote:

On Mon, Jul 29, 2024 at 8:27 PM Mark Thomas  wrote:





The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1504


The Maven repository has not been closed so it is not accessible.


Sorry. Thanks for pointing that out. Fixed.

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

[Mark Thomas]

On 29/07/2024 19:26, Mark Thomas wrote:


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


Tests pass fully on Linux with Tomcat Native 2.0.8 and OpenSSL 3.0.14.

Tests pass on MacOS (Intel and M1) apart from some FFM tests where 
renegotiation is not supported. If forced to run those tests with 
OpenSSL 3.3.1, those tests pass.


Tests pass on Windows apart from FFM tests which are skipped.

Mark

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

[VOTE] Release Apache Tomcat 11.0.0-M23

[Mark Thomas]

The proposed Apache Tomcat 11.0.0-M23 release is now available for
voting.

Apache Tomcat 11.0.0-M23 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:


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

- Add FFM compatibility methods for LibreSSL and BoringSSL support.

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

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-M23/

The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1504

The tag is:
https://github.com/apache/tomcat/tree/11.0.0-M23
2bf2c6a691ad9f2cf68363123419909cebbb308a

The proposed 11.0.0-M23 release is:
[ ] -1 Broken - do not release
[ ] +1 Beta   - go ahead and release as 11.0.0-M23

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

Tagging August releases

[Mark Thomas]

Hi all,

I have a couple of things to finish off (testing Tomcat Native 1.3.1, 
back-porting the translations) but hope to be in a position to tag 
11.0.x later today.


The TCK run seems to be failing consistently for Java 17 and Windows. I 
need to look into why. I haven't been able to reproduce it yet. Unless I 
find something that points clearly to a Tomcat issue, I'm not planning 
on delaying the tags for this.


Mark

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

Re: Requesting the confirmation

[Mark Thomas]

Request denied.

You have yet to make any meaningful contribution to the Tomcat community.

You are remain very, very close to receiving a permanent ban from the 
Tomcat community as a result of multiple nonsense posts.


Mark


On 27/07/2024 04:21, Koteswararao Gundapaneni wrote:

Hi Team,


I got placed to Verizon so I could requesting you to say that I have been
working as a contributor

That will help me to work further


Warm Regards
Koti



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

Re: Simplifying JreCompat

[Mark Thomas]

On 25/07/2024 23:41, Koteswararao Gundapaneni wrote:

I am not sure whether this question is relevant


What is this JreCompat


https://github.com/apache/tomcat/tree/main/java/org/apache/tomcat/util/compat




On Fri, 26 Jul 2024, 02:04 Mark Thomas,  wrote:


As per Rémy's suggestion, I've been looking simplifying JreCompat to
only support LTS versions and anything more recent than the newest LTS.

That would mean:
- Tomcat 9 only
- Jre9Compat is renamed to Jre11Compat
- Tomcat 9 and 10
- Jre16Compat is renamed to Jre17Compat
- All versions
- Jre18Compat and Jre19Compat are merged into the existing Jre21Compat

Jre22Compat would be unchanged.

So the only real change is merging Jre18Compat, Jre19Compat and
Jre21Compat into a single, larger Jre21Compat.

I'm on the fence as to whether this is worth doing. Thoughts?

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: Simplifying JreCompat

[Mark Thomas]

On 25/07/2024 22:49, Rémy Maucherat wrote:

On Thu, Jul 25, 2024 at 10:34 PM Mark Thomas  wrote:


As per Rémy's suggestion, I've been looking simplifying JreCompat to
only support LTS versions and anything more recent than the newest LTS.

That would mean:
- Tomcat 9 only
- Jre9Compat is renamed to Jre11Compat
- Tomcat 9 and 10
- Jre16Compat is renamed to Jre17Compat
- All versions
- Jre18Compat and Jre19Compat are merged into the existing Jre21Compat

Jre22Compat would be unchanged.

So the only real change is merging Jre18Compat, Jre19Compat and
Jre21Compat into a single, larger Jre21Compat.

I'm on the fence as to whether this is worth doing. Thoughts?


Changing the existing does not seem that worthwhile. I sent the idea
because adding a Java 18 class now seemed weird.


Understood. I did it that way mostly for consistency with the existing code.

The existing JreCompat implementations support a feature so it makes 
(more) sense to enable the feature in as many JRE versions as possible.


This feature is a little different since there is a range of JRE 
versions that support both versions of the method. On that basis, I'm 
not against refactoring it to Jre21Compat and dropping Jre18Compat.


Mark

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

Simplifying JreCompat

[Mark Thomas]

As per Rémy's suggestion, I've been looking simplifying JreCompat to 
only support LTS versions and anything more recent than the newest LTS.


That would mean:
- Tomcat 9 only
  - Jre9Compat is renamed to Jre11Compat
- Tomcat 9 and 10
  - Jre16Compat is renamed to Jre17Compat
- All versions
  - Jre18Compat and Jre19Compat are merged into the existing Jre21Compat

Jre22Compat would be unchanged.

So the only real change is merging Jre18Compat, Jre19Compat and 
Jre21Compat into a single, larger Jre21Compat.


I'm on the fence as to whether this is worth doing. Thoughts?

Mark

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

Re: (tomcat) 01/03: Add JreCompat support for Subject.callAs()

[Mark Thomas]

On 25/07/2024 11:31, Michael Osipov wrote:

On 2024/07/25 08:42:52 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

commit a2384804c527c64290cfae1fa988f1f394890e91
Author: Mark Thomas 
AuthorDate: Wed Jul 24 17:51:24 2024 +0100

 Add JreCompat support for Subject.callAs()
 
 With the changes coming in Java 23 we need to move away from

 Subject.doAs() but the replacement isn't available in Java 17. Hence use
 JreCompat.
---
  .../org/apache/tomcat/util/compat/Jre18Compat.java | 71 ++
  .../org/apache/tomcat/util/compat/Jre19Compat.java |  2 +-
  java/org/apache/tomcat/util/compat/JreCompat.java  | 39 
  .../tomcat/util/compat/LocalStrings.properties |  1 +
  4 files changed, 112 insertions(+), 1 deletion(-)

diff --git a/java/org/apache/tomcat/util/compat/Jre18Compat.java 
b/java/org/apache/tomcat/util/compat/Jre18Compat.java
new file mode 100644
index 00..b83999f179
--- /dev/null
+++ b/java/org/apache/tomcat/util/compat/Jre18Compat.java
@@ -0,0 +1,71 @@
+/*
+ *  Licensed to the Apache Software Foundation (ASF) under one or more
+ *  contributor license agreements.  See the NOTICE file distributed with
+ *  this work for additional information regarding copyright ownership.
+ *  The ASF licenses this file to You under the Apache License, Version 2.0
+ *  (the "License"); you may not use this file except in compliance with
+ *  the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ */
+package org.apache.tomcat.util.compat;
+
+import java.lang.reflect.InvocationTargetException;
+import java.lang.reflect.Method;
+import java.util.concurrent.Callable;
+import java.util.concurrent.CompletionException;
+
+import javax.security.auth.Subject;
+
+import org.apache.juli.logging.Log;
+import org.apache.juli.logging.LogFactory;
+import org.apache.tomcat.util.res.StringManager;
+
+public class Jre18Compat extends JreCompat {
+
+private static final Log log = LogFactory.getLog(Jre18Compat.class);
+private static final StringManager sm = 
StringManager.getManager(Jre18Compat.class);
+
+private static final Method callAsMethod;
+
+static {
+Method m1 = null;
+
+try {
+m1 = Subject.class.getMethod("classAS", Subject.class, 
Callable.class);


Am I stupid or isn't the method called "callAs"?

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/javax/security/auth/Subject.html#callAs(javax.security.auth.Subject,java.util.concurrent.Callable)


My typo. Not sure how I managed to get from "callAs" to that. I'm in the 
middle of updating my test environment so I could check that commit. 
I'll fix that now. I don't plan to back-port until I confirm everything 
is working as expected.


Mark

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

Re: (tomcat) 01/03: Add JreCompat support for Subject.callAs()

[Mark Thomas]

On 25/07/2024 13:42, Rémy Maucherat wrote:

On Thu, Jul 25, 2024 at 10:44 AM  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

commit a2384804c527c64290cfae1fa988f1f394890e91
Author: Mark Thomas 
AuthorDate: Wed Jul 24 17:51:24 2024 +0100

 Add JreCompat support for Subject.callAs()

 With the changes coming in Java 23 we need to move away from
 Subject.doAs() but the replacement isn't available in Java 17. Hence use
 JreCompat.
---
  .../org/apache/tomcat/util/compat/Jre18Compat.java | 71 ++


This could be needlessly fancy to add this now. Maybe JreCompat could
be rounded up to the next LTS once they are released. Nobody is going
to use 18 or 19 anymore (21 will be used instead).


That is certainly worth looking at. I'll take a look at the refactoring 
once I've confirmed SPNEGO is still working.


Mark

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

[ANN] Apache Tomcat Native 2.0.8 released

[Mark Thomas]

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

The key features of this release are:

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

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


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

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

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


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

[VOTE][RESULT] Release Apache Tomcat Native 2.0.8

[Mark Thomas]

The following votes were cast:

Binding:
+1: remm, markt, schultz

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

[VOTE][RESULT] Release Apache Tomcat Native 1.3.1

[Mark Thomas]

The following votes were cast:

Binding:
+1: remm, markt, schultz

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: Performance improvements for HTTP/2

[Mark Thomas]

On 23/07/2024 21:30, Christopher Schultz wrote:

Mark,

On 7/23/24 13:13, Mark Thomas wrote:
Prompted by some folks at $dayjob, I have been looking at the 
performance of Tomcat's HTTP/2 implementation using [1]


Initially, I was seeing ~79k req/s.

Restoring lazy init for the StreamInputBuffer increased that to ~106k 
req/s.


O_O

Moving the HttpParser from Processor to Protocol increased that to 
~108k req/s.


Now I am looking at recycling and reusing the coyote request and 
response. That increases throughput to 124k req/s.


This information would be good to put (with a datestamp and 
environmental details) into the documentation for discardFacades and/or 
similar capabilities.


In Bratislava, we idly speculated that "throwing those objects away 
should not affect performance much and improve security" but if it 
really is a 15% speed improvement, it might be really critical for some 
applications.


It really does depend on which objects you are talking about. Looking at 
the flame graph for HTTP/2, it appears that the objects that require the 
creation of buffers are the expensive ones to create. I thought we were 
talking about the (inexpensive) facades in Bratislava.


Someone (I forget who) tested the performance impact of not recycling 
the processors and it was horrible.


Given the significant performance increase I am considering the 
following:

- switching HTTP/2 to recycle and reuse coyote request and response
   objects by default


Note that we just changed that default in the other direction for 
HTTP/1.1. I think we should probably be consistent.


I think you might be getting your objects mixed up. There are three sets:
a) coyote request/response
b) catalina request/response
c) catalina request/response facade

Currently HTTP/2 recreates all of the above for every stream.

HTTP/1.1 always recycles and re-uses a) and b). It is c) that we changed 
to always create new objects by default for 9.0.x (to align with 10.1.x 
and 11.0.x).


This proposal would align HTTP/2 with HTTP/1.1 and recycle and re-use a) 
and b) by default but with an option to re-create every time (mainly in 
case there is a regression due to an application and/or Tomcat issue).



- providing an option to restore the current behaviour of creating a new
   coyote request and response object for every HTTP/2 stream


+1 but with a different default.


If that is for alignment with HTTP/1.1 then I disagree. We should 
recycle and re-use a) and b). If it is to avoid possible regressions 
then I think there is a discussion to be had due to the the performance 
benefits vs regression risk trade off.


Mark

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

Re: TCK CI runs

[Mark Thomas]

On 23/07/2024 23:38, Christopher Schultz wrote:

On 7/23/24 03:05, Mark Thomas wrote:




Given that we are free to make factual statements such as "Tomcat 
11.0.x passes the latest Annotations, EL, Pages, Servlet and WebSocket 
TCKs" or "Tomcat 11.0.0-M20 is a compatible implementation of the 
Jakarta Servlet 6.0 specification" I'm not at all convinced of the 
need to use a logo.


It looks like we might be able to get a pass... sort of.

 From [1]:

"
Use of the “Jakarta EE Compatible” mark is limited to use in conjunction 
with Compatible Software Products (as defined below) distributed by:


     Participant, Enterprise or Strategic Members of the Jakarta EE WG
   who are also licensees under the Jakarta EE Compatibility
   Trademark License Agreement; or
     Guest Members of the Jakarta EE WG, if:
     Use of the Jakarta EE Compatible mark is approved unanimously by
     the Jakarta EE WG Steering Committee; and Such Guest Members
     are also licensees under the Eclipse Foundation Trademark
     License.
"

So we would need to be a licensee of their trademark license. We could 
ask to become a "Guest Member" of the Jakarta EE WG. I don't know what 
that entails.


The ASF is currently:

- an associate Eclipse Foundation member [1]
- a guest member of the Jakarta EE working group [2]

The trademark license agreement [3] requires (section 2.2) that the ASF 
is both:

 (i) be a Qualified Eclipse Member
(ii) be a Qualified Working Group Member

As per the definitions:
“Qualified Eclipse Member” shall mean a Strategic or Contributing
Member of Eclipse
“Qualified Working Group Member” shall mean a Participant, Enterprise
or Strategic Member of a Working Group.

The ASF doesn't, currently, meet either of those requirements. There are 
other requirements around passing the TCK and publishing the results 
that I believe we can/do easily meet.


Even if Eclipse was amenable to the ASF meeting the above requirements 
at zero cost to the ASF (probably possible) there is the time and effort 
require to make that happen.


While overcoming all of the above is possible, it seems like a lot of 
work to gain permission to use a logo none of our users seem concerned 
about. I'm not even sure any of them care about formal certification. 
They certainly never ask about it.


Mark




[1] https://www.eclipse.org/membership/explore-membership/
[2] https://jakarta.ee/membership/members/
[3] 
https://jakarta.ee/legal/trademark_guidelines/jakarta-ee-trademark-license.pdf




-chris

-
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: TCK CI runs

[Mark Thomas]

On 23/07/2024 15:33, Christopher Schultz wrote:



I just meant kinda being able to run a single command to do all the 
things, including fetch the release to be tested. I haven't checked-out 
the tomcat-tck project to test; maybe you've already done that. But if 
the first step of the instructions is "okay, go download these 19 
things" nobody will ever do it.


I find that every tie I want to build httpd from source I have that 
experience, and it totally sucks.


git clone
mvn -Dtomcat.version=11.0.0-M22 verify

which will fail because of the annotations TCK. You need to use the 
default of 11.0.0-M23-SNAPSHOT to see it pass.



I'll try to give it a shot sometime this week and see how it goes for me.


Great. Confirming it works for others would be a good thing (tm).

Mark

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

Performance improvements for HTTP/2

[Mark Thomas]

Prompted by some folks at $dayjob, I have been looking at the 
performance of Tomcat's HTTP/2 implementation using [1]


Initially, I was seeing ~79k req/s.

Restoring lazy init for the StreamInputBuffer increased that to ~106k req/s.

Moving the HttpParser from Processor to Protocol increased that to ~108k 
req/s.


Now I am looking at recycling and reusing the coyote request and 
response. That increases throughput to 124k req/s.


Given the significant performance increase I am considering the following:
- switching HTTP/2 to recycle and reuse coyote request and response
  objects by default
- providing an option to restore the current behaviour of creating a new
  coyote request and response object for every HTTP/2 stream

Thoughts?

Mark


[1] https://github.com/sdeleuze/spring-boot-http2

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

Re: [VOTE] Release Apache Tomcat Native 1.3.1

[Mark Thomas]

Ping. We are 1 PMC member +1 vote short for this release.

Mark


On 18/07/2024 11:00, Mark Thomas wrote:

The key differences compared to 1.3.0 are:

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

The proposed release artifacts can be found at [1],
and the build was done using tag [2].

The Apache Tomcat Native 1.3.1 release is
  [ ] Stable, go ahead and release
  [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/1.3.1
[2] 
https://github.com/apache/tomcat-native/commit/0d6da8c122e88bba17bf49d0ada443311b2baab6


-
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 Native 2.0.8

[Mark Thomas]

Ping. We are 1 PMC member +1 vote short for this release.

Mark

On 17/07/2024 20:51, Mark Thomas wrote:

The key differences of version 2.0.8 compared to 2.0.7 are:

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

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


The proposed release artifacts can be found at [1],
and the build was done using tag [2].

The Apache Tomcat Native 2.0.8 release is
  [ ] Stable, go ahead and release
  [ ] Broken because of ...

Thanks,

Mark


[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.8
[2] 
https://github.com/apache/tomcat-native/commit/da9d510960b8cef95359b08b30ec1dba995183eb


-
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: TCK CI runs

[Mark Thomas]

On 22/07/2024 23:33, Christopher Schultz wrote:

Mark,

On 7/22/24 12:53, Mark Thomas wrote:

All,

Today I have configured the tomcat-tck repository to run the EL, 
Servlet, Pages and WebSocket TCKs once every day for all combinations 
of JDK 17 & 21, Ubuntu latest, MacOS latest and Windows latest using 
GitHub actions.


There were a few issues to iron out but these should now all be resolved.

The TCK will run at just after 08.00 UTC every day and it will use the 
latest Tomcat 11 SNAPSHOT (these are updated on every commit by 
buildbot).


Windows seems to take a little longer than the others but the full TCK 
run (all four TCKs) is complete in just under 25 minutes. Considering 
it used to take longer than that to run any of the old TCKs, kudos to 
the Jakarta EE folks that have been working on the refactoring.


Tomcat 11.0.x currently passes the TCK (as it should).

I have no plans to formally certify Tomcat as passing the TCK over and 
above what I have already completed as part of the release process for 
each of the specifications (the specification release process requires 
at least one compatible implementation).


Nice work.

My guess is that getting Tomcat to be formally-certified would take (1) 
money (2) politics and (3) other stuff nobody wants to deal with any 
time soon.


For certification the bar is pretty low. It would probably take longer 
on the Eclipse side getting the certified version added to the various 
websites than it would be on the ASF side doing the actual certification.


Whether even that low level of effort is something we want to do is TBD. 
There is very little (no?) demand from users for formal certification.


The real value to me is in running and passing the tests. Therefore, 
I'll probably use the tomcat-tck repo to test each release candidate as 
it is published and include those results in my vote. I haven't figured 
out how to automate that but I am thinking about it.


If we want to use the "Jakarta EE compatible" logo then that is where we 
hit your points 1, 2 and 3 in spades.


We'd need to sign a trademark agreement and my reading of that is that 
the ASF does not currently have the right membership of Eclipse to be 
able to use the logo. Fixing that looks likely to take some time and 
politics to resolve - particularly since the ASF is unlikely to want to 
pay for am Eclipse membership.


Given that we are free to make factual statements such as "Tomcat 11.0.x 
passes the latest Annotations, EL, Pages, Servlet and WebSocket TCKs" or 
"Tomcat 11.0.0-M20 is a compatible implementation of the Jakarta Servlet 
6.0 specification" I'm not at all convinced of the need to use a logo.


I wonder if we made it so easy to certify (e.g. automated builds and 
automated TCK executions) that someone else might just do it for us (I'm 
looking at you, /Eclipse Foundation/.. I seem to remember a conference 
presentation about how important Tomcat was to Eclipse).


It is easy enough for anyone to perform the certification.

When the TCK runs, does it produce a report which includes the 
identities of the files that were used to run produce that report? 
Specifically, I'm wondering if the TCK report can be used to verify that 
a *specific release* has passed and TCK and that can be verified by an 
external observer.


No. But all the information required is there in the Maven build. It 
probably needs a simple(ish) Maven plugin to generate it.


I'm not volunteering to add TCK runs as part of the standard release 
process but if "anyone" could produce a TCK report which shows the 
entirely-reproducible build that is Tomcat x.y.z is what has been 
tested, that would be really great.


It should only take a couple of minutes to generate the required 
information manually from one of the GitHub action runs.


Instead of just "trust me, I ran it on my machine and this report says 
it passed", anyone could verify that the same artifacts we released were 
the ones the TCK was run on.


They can do that now. One of the benefits of getting the TCK running as 
a GitHub action was that it forced me to fix all places I wasn't aware 
of that the tomcat-tck repo was depending on things I already had 
installed on my dev machine.


Mark

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

TCK CI runs

[Mark Thomas]

All,

Today I have configured the tomcat-tck repository to run the EL, 
Servlet, Pages and WebSocket TCKs once every day for all combinations of 
JDK 17 & 21, Ubuntu latest, MacOS latest and Windows latest using GitHub 
actions.


There were a few issues to iron out but these should now all be resolved.

The TCK will run at just after 08.00 UTC every day and it will use the 
latest Tomcat 11 SNAPSHOT (these are updated on every commit by buildbot).


Windows seems to take a little longer than the others but the full TCK 
run (all four TCKs) is complete in just under 25 minutes. Considering it 
used to take longer than that to run any of the old TCKs, kudos to the 
Jakarta EE folks that have been working on the refactoring.


Tomcat 11.0.x currently passes the TCK (as it should).

I have no plans to formally certify Tomcat as passing the TCK over and 
above what I have already completed as part of the release process for 
each of the specifications (the specification release process requires 
at least one compatible implementation).


Mark

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

Re: (tomcat) 06/07: Add HTTP/2 support for early hints

[Mark Thomas]

On 19/07/2024 16:19, Koteswararao Gundapaneni wrote:

Hi Mark,


OpenclientConnection should be ftp rather than tcpip

Re
Koti


And the above complete and utter nonsense is the point where my patience 
is exhausted. Any more posts like this and a ban will be applied without 
further comment or warning.


Mark







On Fri, 19 Jul 2024, 21:56 ,  wrote:


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

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

commit ae22fadba4b94152fa5cc1d015ed2058f21e3164
Author: Mark Thomas 
AuthorDate: Thu Jul 4 16:53:21 2024 +0100

 Add HTTP/2 support for early hints
---
  java/org/apache/coyote/http2/Stream.java   | 16 ++
  java/org/apache/coyote/http2/StreamProcessor.java  |  3 +-
  .../apache/coyote/http2/TestStreamProcessor.java   | 66
++
  3 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/java/org/apache/coyote/http2/Stream.java
b/java/org/apache/coyote/http2/Stream.java
index a72bba3a7b..3e621e82a8 100644
--- a/java/org/apache/coyote/http2/Stream.java
+++ b/java/org/apache/coyote/http2/Stream.java
@@ -597,6 +597,22 @@ class Stream extends AbstractNonZeroStream implements
HeaderEmitter {
  }


+final void writeEarlyHints() throws IOException {
+MimeHeaders headers = coyoteResponse.getMimeHeaders();
+String originalStatus = headers.getHeader(":status");
+headers.setValue(":status").setString("103");
+try {
+handler.writeHeaders(this, 0, headers, false,
Constants.DEFAULT_HEADERS_FRAME_SIZE);
+} finally {
+if (originalStatus == null) {
+headers.removeHeader(":status");
+} else {
+headers.setValue(":status").setString(originalStatus);
+}
+}
+}
+
+
  @Override
  final String getConnectionId() {
  return handler.getConnectionId();
diff --git a/java/org/apache/coyote/http2/StreamProcessor.java
b/java/org/apache/coyote/http2/StreamProcessor.java
index 3f3cde6f50..b7d6e9e6ce 100644
--- a/java/org/apache/coyote/http2/StreamProcessor.java
+++ b/java/org/apache/coyote/http2/StreamProcessor.java
@@ -263,8 +263,7 @@ class StreamProcessor extends AbstractProcessor {

  @Override
  protected void earlyHints() throws IOException {
-// TODO Auto-generated method stub
-// NO-OP for now
+stream.writeEarlyHints();
  }


diff --git a/test/org/apache/coyote/http2/TestStreamProcessor.java
b/test/org/apache/coyote/http2/TestStreamProcessor.java
index ac362c6e30..5082349a6e 100644
--- a/test/org/apache/coyote/http2/TestStreamProcessor.java
+++ b/test/org/apache/coyote/http2/TestStreamProcessor.java
@@ -36,6 +36,7 @@ import org.junit.Test;
  import org.apache.catalina.Context;
  import org.apache.catalina.Wrapper;
  import org.apache.catalina.connector.Connector;
+import org.apache.catalina.connector.ResponseFacade;
  import org.apache.catalina.startup.Tomcat;
  import org.apache.tomcat.util.compat.JrePlatform;
  import org.apache.tomcat.util.http.FastHttpDateFormat;
@@ -586,4 +587,69 @@ public class TestStreamProcessor extends
Http2TestBase {
  String trace = output.getTrace();
  Assert.assertTrue(trace,
trace.contains("3-Header-[:status]-[501]"));
  }
+
+
+@Test
+public void testEarlyHints() throws Exception {
+enableHttp2();
+
+Tomcat tomcat = getTomcatInstance();
+
+Context ctxt = getProgrammaticRootContext();
+Tomcat.addServlet(ctxt, "simple", new SimpleServlet());
+ctxt.addServletMappingDecoded("/simple", "simple");
+Tomcat.addServlet(ctxt, "ehs", new EarlyHintsServlet());
+ctxt.addServletMappingDecoded("/ehs", "ehs");
+tomcat.start();
+
+openClientConnection();
+doHttpUpgrade();
+sendClientPreface();
+validateHttp2InitialResponse();
+
+// Disable overhead protection for window update as it breaks
some tests
+http2Protocol.setOverheadWindowUpdateThreshold(0);
+
+byte[] headersFrameHeader = new byte[9];
+ByteBuffer headersPayload = ByteBuffer.allocate(128);
+
+buildGetRequest(headersFrameHeader, headersPayload, null, 3,
"/ehs");
+
+// Write the headers
+writeFrame(headersFrameHeader, headersPayload);
+
+parser.readFrame();
+
+Assert.assertEquals("3-HeadersStart\n" +
"3-Header-[:status]-[103]\n" +
+"3-Header-[link]-[; rel=preload; as=style]\n"
+ "3-HeadersEnd\n", output.getTrace());
+output.clearTrace();
+
+parser.readFrame();
+parser.readFrame();
+
+Assert.assertEquals("3-HeadersStart\n" +
"3-Header-[:status]-[200]\n" +
+"3-Header-[l

Re: Security mechanisms to counter spam

[Mark Thomas]

On 19/07/2024 16:08, Koteswararao Gundapaneni wrote:

Hi Dimitris,

We could potentially block but it is as per the agreement


This comment makes no sense.

If you continue to make nonsensical comments to the dev@ list, GitHub, 
Bugzilla or similar then you will be blocked from making any comments.


If English is not your first language, I would strongly encourage you to 
use Google Translate or a similar service.


Mark





On Fri, 7 Jun 2024, 15:53 Dimitris Soumis,  wrote:


Hi All,

Due to the surge in spam BZs today, I propose implementing a security
mechanism to counter this issue and prevent further disruption to the
mailing list.

A potential solution could include a honeypot to identify and block bots,
as well as a reCaptcha to verify users. Additionally, should monitor for
multiple requests from the same IP address and block the IP if necessary.

Can also leverage tools like this Mozilla Bugbot Spam Detection Script
 to
identify and filter out spam.

Best regards,

Dimitris





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

Re: Short and long term plans for Tomcat Native

[Mark Thomas]

On 19/07/2024 16:03, Koteswararao Gundapaneni wrote:

Hi Mark


Do we need the app is maintained or to be noticed


This comment makes no sense.

If you continue to make nonsensical comments to the dev@ list, GitHub, 
Bugzilla or similar then you will be blocked from making any comments.


If English is not your first language, I would strongly encourage you to 
use Google Translate or a similar service.


Mark




On Wed, 17 Jul 2024, 21:04 Mark Thomas,  wrote:


All,

I've spent some time today trying to build Tomcat Native with Visual
Studio 2022 rather then the current, more involved process without success.

Therefore, my short-term plan for Tomcat Native is to get the next 2.0.x
and 1.3.x releases completed using the existing build process. I'll be
starting that shortly.

Longer term, thinking about Tomcat Native and FFM I have the following
rough plan in mind:

- stop providing x86 binaries for Windows
- require Windows 10 onwards
- provide:
- libssl.dll
- libcrypto.dll
- tomcat-native-2.dll
- openssl.exe

along with appropriate debug symbols.

I'm not sure if we'd need an apr.dll in there as well.

The idea is that users can then use either the AprLifecycleListener or
OpenSSLLifecycleListener.

This would probably require moving Tomcat Native to 2.1.x and 1.4.x

This really needs someone more familiar with building C libraries
generally and these libraries in particular - i.e. Mladen - to say
whether the above is possible and to provide some pointers on how to do it.

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 Native 1.3.1

[Mark Thomas]

On 18/07/2024 11:00, Mark Thomas wrote:


The Apache Tomcat Native 1.3.1 release is
  [X] Stable, go ahead and release
  [ ] Broken because of ...


Tests was for the APR connector on 9.0.x with the non-OCSP Windows binary.

Mark

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

Re: (tomcat-native) branch 1.3.x updated: Align with 9.0.x

[Mark Thomas]

On 18/07/2024 12:27, Konstantin Kolinko wrote:

чт, 18 июл. 2024 г. в 11:42, :





@@ -287,6 +312,28 @@ public final class Library {
  return initialize();
  }

+
+public static boolean tryCleanUpLock(long cleanupGeneration) {
+try {
+boolean result = cleanUpLock.readLock().tryLock(0, 
TimeUnit.SECONDS);
+if (result &&  generation.get() == cleanupGeneration) {
+return true;
+}
+cleanUpLock.readLock().unlock();
+} catch (InterruptedException e) {
+// Treated the same way as not getting the lock
+}
+return false;
+}


Mark,

I think there is a bug with the "readLock().unlock()" call above. It
should be called only when the "result" of preceding tryLock() is
true.

Calling unlock() when no lock is held results in an
IllegalMonitorStateException. [1]

I see that this code is present on the 9.0.x branch only (and not on
the 10.1.x and main branches).

[1] 
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/concurrent/locks/ReentrantReadWriteLock.ReadLock.html


Thanks for the review. I've fixed this in 9.0.x. This will get picked up 
for Tomcat Native for 1.3.2 onwards.


Mark

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