Re: tomcat version retirement plan

2022-11-24 Thread Mark Thomas




On 24/11/2022 09:53, Rathore, Rajendra wrote:

Hi Team,

Can you please share the timeline for retiring the individual tomcat release ?

Tomcat retirement plan date(tentative)
8.5.x
9.x.x
10.0.x
10.1.x

Based on above table we will plan which tomcat is long term supported so that 
we can use it for our software.


Arguably all our major versions receive long term support. They are 
generally supported for around 10 years.


Note that, as previously discussed, 10.0.x is EOL now that 10.1.x is stable.

We support 3 major releases in parallel. So 8.5.x will be EOL when 
11.0.x is stable (best guess ~April 2024). There should be a formal 
announcement for 8.5.x soon.


Then, major releases are typically released every 3 to 3.5 years.

9.x is a special case since it is the last version that supports Java 
EE. The exact plan is TBD but rather than 9.0.x being made EOL, there 
will be something like a 9.10.x (10.1.x but with the Java EE API) and 
then 9.11.x etc for as long as there is user demand and committer 
support for providing it.


If you are starting a project now, use 10.x.

Mark

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



Re: listing (db) resources

2022-11-22 Thread Mark Thomas

Take a look at how the ManagerServlet lists resources:

https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/manager/ManagerServlet.java#L1193

Hopefully that will give you some pointers.

Mark


On 22/11/2022 14:56, Rob Sargent wrote:
I trying to get the list of available db resources to send to a web 
page.   My context.xml file below is generated at startup since the 
user(s) and dbs change regularly and I would like to see "who's on 
first" from my monitor servlet.  I tried context.getEnvironment() but 
that's empty.  Is there programmatic access t the list of Resource names?


    

    

    

       
       
    




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



Re: HTTP/2 connection broken (RST_STREAM) when multiple timeouts waiting for data from client

2022-11-18 Thread Mark Thomas




On 18/11/2022 10:21, Mark Thomas wrote:

On 17/11/2022 20:01, Gonzalo Fernandez wrote:




The problem happens when a client with an open TCP / HTTP2 connection
sends multiple incomplete streams, which seems to block the connection
forever and not be able to accept new streams.

In detail, using tcpdump, we are seeing that the Tomcat Server
receives the HEADER frame, but never receives the following DATA
frames for a stream. After 20 seconds (streamReadTimeout default
value), the Tomcat Server throws a "client timeout" exception
(stacktrace at the end of the mail), and returns "400 Bad Request"
followed by a RST_STREAM frame.
The problem is that when the amount of incomplete streams surpasses
the value of "maxConcurrentStreams", the connection starts to return
RST_STREAM to any new stream indefinitely, it never recovers. I
verified this by changing the value of that property and looking at
the number of streams in every connection. When the value wasn't
defined, it took 100 incomplete streams over the same connection to
break it, then I changed to 20 and it took 20 incomplete streams to
break it.

This makes me suspicious that the concurrent streams counter isn't
being decreased when this happens, and could possibly be a bug. I
tried to identify this in the tomcat codebase but I am not familiar
enough with it.


Thanks for the very detailed description.

Your suspicion is correct. There is a Tomcat bug here. I have been able 
to write a test case that demonstrates the bug and am working on a fix.


I just wanted to say how much the effort you put into researching this 
is appreciated. Your report has exactly the right amount of detail we 
need. Enough to see exactly what the problem is and to recreate the 
problem and no unnecessary extra information.


I should have a patch for this shortly.


Fixed in:
- 10.1.x for 10.1.3  onwards
-  9.0.x for  9.0.70 onwards
-  8.5.x for  8.5.85 onwards

Mark

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



Re: HTTP/2 connection broken (RST_STREAM) when multiple timeouts waiting for data from client

2022-11-18 Thread Mark Thomas

On 17/11/2022 20:01, Gonzalo Fernandez wrote:




The problem happens when a client with an open TCP / HTTP2 connection
sends multiple incomplete streams, which seems to block the connection
forever and not be able to accept new streams.

In detail, using tcpdump, we are seeing that the Tomcat Server
receives the HEADER frame, but never receives the following DATA
frames for a stream. After 20 seconds (streamReadTimeout default
value), the Tomcat Server throws a "client timeout" exception
(stacktrace at the end of the mail), and returns "400 Bad Request"
followed by a RST_STREAM frame.
The problem is that when the amount of incomplete streams surpasses
the value of "maxConcurrentStreams", the connection starts to return
RST_STREAM to any new stream indefinitely, it never recovers. I
verified this by changing the value of that property and looking at
the number of streams in every connection. When the value wasn't
defined, it took 100 incomplete streams over the same connection to
break it, then I changed to 20 and it took 20 incomplete streams to
break it.

This makes me suspicious that the concurrent streams counter isn't
being decreased when this happens, and could possibly be a bug. I
tried to identify this in the tomcat codebase but I am not familiar
enough with it.


Thanks for the very detailed description.

Your suspicion is correct. There is a Tomcat bug here. I have been able 
to write a test case that demonstrates the bug and am working on a fix.


I just wanted to say how much the effort you put into researching this 
is appreciated. Your report has exactly the right amount of detail we 
need. Enough to see exactly what the problem is and to recreate the 
problem and no unnecessary extra information.


I should have a patch for this shortly.

Mark

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



Re: Why does LockOutRealm not support CredentialHandler?

2022-11-17 Thread Mark Thomas

On 17/11/2022 10:07, Rémy Maucherat wrote:

On Wed, Nov 16, 2022 at 6:14 PM Christopher Schultz





I guess we could add a configuration option to CombinedRealm:

 inheritCredentialHandler="first|last|numeric-position|false/off/no"

?

Then you'd only have to declare it once and then you have the
flexibility of inheriting it or not. But you'd have to opt-into it
instead of getting a surprise.


Right now the feature is simply too weird, so I'll simply improve it:
- It doesn't work if this is a CombinedRealm, so since they are now
used all the time this is rather annoying.
- For some reason it only sets the attribute if the Realm is on the
Context. For example it will not set anything if the realm is on the
Host.

So instead, I will make these changes:
- CombinedRealm will get its own special credential handler if none is
set (it will behave like the nested credential handler, except on
nested realm.getCredentialHandler()).
- In StandardContext, the attribute will be set based on getRealm()
instead of getRealmInternal().


I don't think we do that as it creates a security concern. An untrusted 
application would be able to brute force a Realm it hasn't defined.


A trusted app can obtain a reference to the Realm via other means.

I know untrusted apps are rare and becoming rarer but at long as we have 
to support the SecurityManager (hopefully not for much longer) then we 
have to consider untrusted apps.


Mark

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



Re: Tomcat-embed and Tomcat Vulnerabilities

2022-11-17 Thread Mark Thomas

On 16/11/2022 23:45, David Alejandro Christensen Arreola wrote:

Hi Users,

My question is about whether a vulnerability applies to my particular 
application. My application is using tomcat-embed.

Being tomcat-embed derived from Tomcat server, could tomcat-embed has the 
vulnerabilities that Tomcat server has?


Yes.


In affirmative case, is disclosure of vulnerability going to mention 
tomcat-embed or Tomcat Server only when applicable?


No. Vulnerabilities apply to all configurations unless the vulnerability 
description explicitly states otherwise.


Mark

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



Re: How do auth-method BASIC and DIGEST play together with some credential helper?

2022-11-15 Thread Mark Thomas
Sorry, you are correct. There is no way to use PBKDF2WithHmacSHA512 in a 
Realm along with HTTP DIGEST auth.


If you want to use HTTP DIGEST auth and digested passwords on the server 
you have to use, quoting the Tomcat docs, "one iteration of the MD5 
algorithm with no salt".


RFC 7616 has added SHA2-256 and SHA2-512/256 to DIGEST auth. That is an 
improvement but still not great. Tomcat has not been updated to support 
those. Neither has any major browser. I suspect they never will.


Assuming digesting passwords with one round of MD5 and no salt isn't 
acceptable (I'd be surprised if it was) then you are probably looking at 
HTTPS + BASIC + PBKDF2WithHmacSHA512.


There are a few other options but they come with significant caveats:

- If all the users are Windows domain users then SPNEGO is an
  alternative.

- HTTPS + CLIENT_CERT is also an option but the management overhead of
  issuing clients with certificates is significant.

- It is possible to integrate OAuth2 via JASPIC. There is a library to
  do that for Google. There may be libraries for other providers.

Beyond that you would need to start looking at a 3rd party security library.

Mark




On 15/11/2022 18:23, Thorsten Schöning wrote:

Guten Tag Mark Thomas,
am Dienstag, 15. November 2022 um 18:36 schrieben Sie:


Please go and read my email - and the links I provided - again.


I did, so feel free to tell me how I tell my browser to use my
plain-text password as PBKDF2WithHmacSHA512 digest with 10
iterations, a key length of 256 bits and a salt of 16 bytes. Because
my browser's dialog asking for username and password doesn't allow me
to put any of these options in.

Are you sure to have understood that I already know how to store a
digest with those settings in tomcat-users.xml? That wasn't the
question. The question was this aspect from your own link:


When the authenticate() method of the Realm is called, the
(cleartext) password specified by the user is itself digested by the
same algorithm[...]


There is no cleartext password from the user from the browser if
"DIGEST" is used. The cleartext password
needs to be available in tomcat-users.xml, but isn't when using
PBKDF2WithHmacSHA512.

Mit freundlichen Grüßen

Thorsten Schöning



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



Re: accessing external contents

2022-11-15 Thread Mark Thomas

On 14/11/2022 11:22, Umesh Raikwar wrote:




... context path /product ...







   loaderClass="org.apache.catalina.loader.ParallelWebappClassLoader" 
delegate="true"/>

   
   
     


and tried to access URL: locahost:8080/Product/test.html which returned 
404.



My question:
Is nested components the right way to achieve the requirement? If yes, 
please help me understand what I am missing. If not, please point me the 
right way.


You are on the right track. I've just tested this locally and it works.

You have inconsistent context paths in your question. URLs are case 
sensitive. That makes me think you have the wrong context path somewhere.


It might be helpful it you started with a standard Tomcat install. 
Adding the following to $CATALINA_BASE/webapps/manager/META-INF/context.xml



  


allows me to access $CATALINA_BASE/extras/test.jsp via 
http://localhost:8080/manager/test.jsp


Mark

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



Re: "You don't have permission to access this resource." message on manager

2022-11-15 Thread Mark Thomas

On 15/11/2022 17:41, James H. H. Lampert wrote:

We have Tomcat running on an AWS EC2 linux box.

I can get into manager from the office IP address, with the usual prompt 
for user and password, but the boss, working from home, gets "You don't 
have permission to access this resource."


Is this from Tomcat, or is it from something else?


Lots of guess work here.

I think, something else.


Looking at the context.xml for manager, I see:



 From what little I know about this, my own ability to get in is more 
puzzling than my boss's inability to do so. Any insights on that?


Tomcat will be behind some sort of load-balancer. Requests from the 
load-balancer may appear to be coming from localhost. Have a look at the 
Tomcat access logs for the client IP addresses.


My guess is the load-balancer is enforcing the access controls.

Or maybe you are using a VPN to connect to the Tomcat instance. Or ssh 
with port redirection or ...


I never did learn how to write a RemoteAddrValve allow clause (so we've 
just been disabling it); assuming we want to accept connections from 
"1.2.3.4" and "5.6.7.8", could somebody show me what the allow clause 
would look like?


"1\.2\.3\.4|5\.6\.7\.8"

It is a Java regular expression.

Mark

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



Re: How do auth-method BASIC and DIGEST play together with some credential helper?

2022-11-15 Thread Mark Thomas

On 15/11/2022 17:07, Thorsten Schöning wrote:

Guten Tag Mark Thomas,
am Dienstag, 15. November 2022 um 12:51 schrieben Sie:


In short, the digested value you save as the user credential is one
of the inputs the client uses when calculating the value to use in
the authorization header.[...]


My client is a browser and that asks me for plain-text passwords.
There's no way I could provide a digest generated using
PBKDF2WithHmacSHA512 with the settings mentioned in my former mail.
And even if there was, that digest would be a plain-text password
again.


This works.

Please go and read my email - and the links I provided - again.

If there are things you don't understand, ask specific questions.

You may also find reading RFC 7616 useful.

Mark

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



Re: How do auth-method BASIC and DIGEST play together with some credential helper?

2022-11-15 Thread Mark Thomas

On 15/11/2022 10:20, Thorsten Schöning wrote:




So, is it even possible to use SecretKeyCredentialHandler and
auth-method DIGEST together or am I required to use BASIC? If DIGEST
is supported, how does that and credential helper work together
without plain-text password available at the server at all?


Yes. Completely possible. You just have to create the digests in the 
right format.


https://tomcat.apache.org/tomcat-10.1-doc/realm-howto.html#Digested_Passwords

In short, the digested value you save as the user credential is one of 
the inputs the client uses when calculating the value to use in the 
authorization header. The other values are parts of the request and/or 
provided by the server. Hence both the client and server are able to 
calculate the same digest.


See 
https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/realm/RealmBase.java#L389


Mark

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



[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.5

2022-11-08 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.5

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.4 include:

- Narrow scope of javax.annotation conversion to Java EE. Pull request
  by Danny Thomas
- Improve manifest handling and conversion performance. Pull request by
  Danny Thomas.


Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

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

Enjoy!

- The Apache Tomcat team


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



[ANN] Apache Tomcat Native 2.0.2 released

2022-11-08 Thread Mark Thomas

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

The key features of this release are:

- Update the minimum supported version of LibreSSL to 3.5.2.
  Based on a #13 provided by orbea.

- The windows binaries in this release have been built with OpenSSL
  3.0.7

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


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

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

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


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



Re: Tomcat 10 with Http2 and compression sometimes causes pages to load partly in FF

2022-11-07 Thread Mark Thomas

On 06/11/2022 19:35, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,

I found some time for digging into this older topic with the combination http2, 
Firefox, Compression and only partly loaded pages.
I hope I or the topic doesn’t bother you.


Not at all. If there is a Tomcat bug here, I want to get it fixed.


As apache-tomcat-10.0.0-M7 doesn’t show the problem with broken pages in FF 
(jsp page only partly loads) and
it showed up with apache-tomcat-10.0.0-M8, I was taking a look at the changes. 
This was my current approach to this topic.

The change which makes the difference is in Http2UpgradeHandler:
int reserveWindowSize(Stream stream, int reservation, boolean block) throws 
IOException {
...
 if (!stream.canWrite()) {
 
stream.doStreamCancel(sm.getString("upgradeHandler.stream.notWritable",
 stream.getConnectionId(), stream.getIdAsString()), 
Http2Error.STREAM_CLOSED);
 }

The older version just threw an exception instead of calling doStreamCancel 
when the client is closing the stream:

if (!stream.canWrite()) {
 throw new CloseNowException(
 
sm.getString("upgradeHandler.stream.notWritable",
 stream.getConnectionId(), 
stream.getIdentifier()));
 }

The method doStreamCancel is setting some properties before throwing also a 
CloseNowException:

 void doStreamCancel(String msg, Http2Error error) throws CloseNowException 
{
 StreamException se = new StreamException(msg, error, getIdAsInt());
 // Prevent the application making further writes
 streamOutputBuffer.closed = true;
 // Prevent Tomcat's error handling trying to write
 coyoteResponse.setError();
 coyoteResponse.setErrorReported();
 // Trigger a reset once control returns to Tomcat
 streamOutputBuffer.reset = se;
 throw new CloseNowException(msg, se);
 }

The line "streamOutputBuffer.closed = true;" seems to be responsible for the 
partly shown pages in FF.
If I comment out this line, no problem shows up with FF, http2 and 
compression="force".


Nice bit of detective work. Setting streamOutputBuffer.closed=true will 
prevent the application from writing the rest of the resource content 
which would explain the partial response seen on the client side.



This line seems to have some side effect somewhere else.
Unfortunately, I don’t know the code of Tomcat and http2 protocol.
Can you think about which side effect this line might have (in combination with 
compression / GZipOutputFilter)?
Maybe you have an inspiring idea about the cause or have a hint, where to 
follow the track.


I think this is more symptom rather than root cause. The symptom is 
visible because of the change to call doStreamCancel() but the question 
for me is what is triggering this to be called in the first place.


Digging into that a little:

stream.canWrite() needs to return false.

That happens when the Stream is in one of the states that does not 
permit write. Those states are:

IDLE
RESERVED_LOCAL
HALF_CLOSED_LOCAL
CLOSED_RX
CLOSED_TX
CLOSED_RST_RX
CLOSED_RST_TX

One thing we could do is improve the error message so it logs the 
current Stream state. That will help narrow down how the Stream got into 
that state.


I'll get than done for the next set of releases.

Mark

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



Re: Tomcat 9x NIO connector socket timeout

2022-11-07 Thread Mark Thomas
connectionTimeout and socket.soTimeout are the same attribute. The value 
used is the most recent one set regardless of which setter was used.


For the simple case of blocking read/write then the default timeout will 
be the same as connectionTimeout.


Once you get into async, WebSocket and HTTP/2 things get more complex. 
For example, the socket timeout for async is infinite and Tomcat manages 
the async timeout separately.


The docs could do with an update.

Mark


On 04/11/2022 11:45, Pawel Veselov wrote:

Hello.

I was wondering what exact value does Tomcat 9x use for NIO connector
socket timeouts?
I.e., when the following exception occurs:

org.apache.catalina.connector.ClientAbortException
java.net.SocketTimeoutException
at 
org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:353)
at 
org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:783)
at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:688)
at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:388)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:366)
at 
org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:96)

, it means that the underlying socket's .setSoTimeout() has been set
to a positive value.

Reading https://tomcat.apache.org/tomcat-9.0-doc/config/http.html, I see:

socket.soTimeout - "This is equivalent to standard attribute
connectionTimeout". Does it mean that setting this property is the
same as setting connectionTimeout, or that in the absence of
socket.soTimeout being explicitly set, the value of connectionTimeout
is used?

"connectionTimeout" says that it's only about waiting for a request
line after a TCP connection is accepted.

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



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



Re: TLS configuration TLS for JMX port

2022-11-04 Thread Mark Thomas

On 04/11/2022 08:06, Bärtschi, Markus-MGB wrote:


I configured TLS for my JMX post, this is working alright.

But the keystore information, especially the passwords end up on the 
java/tomcat command line.
I did attempt to move the configuration items into catalina.properties, but 
this did not work.

How can I configure TSL for my JMX port without the keystore information 
showing up on the command line ?


Don't use passwords. Rely on operating system file permissions to limit 
access to the file to the Tomcat process (and root).


Keep in mind that JMX has various security issues you can do very little 
about including:


- extremely coarse grained security (read-only or read/write)
- no protection against brute force attacks
- no logging to identify brute force attacks

Note that Tomcat is implemented from the point of view that *any* JMX 
access is equivalent to full administrative access.


Mark

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



Re: Compatibility, 32 bit ..

2022-11-04 Thread Mark Thomas

On 03/11/2022 11:48, John Dale (DB2DOM) wrote:

Greetings - thanks for the pointer below.

Brought up some interesting questions below.

How do changes at Oracle affect Tomcat?  Has OpenJRE sufficiently
insulated the risk?


What changes at Oracle? What risk?

There isn't anything that i am particularly worried about at the moment.



What would you say is the best O/R M tool for tomcat that still keeps
coding hands-on with respect to connection management and MVC handler
deployment/logic?


Sorry, not a clue.


What are some good object databases (are there any) that work well with Tomcat?


Ditto.

Mark




On 11/3/22, Mark Thomas  wrote:

On 02/11/2022 18:51, Christopher Schultz wrote:

John,

On 11/2/22 14:32, John Dale (DB2DOM) wrote:

On 11/2/22, Christopher Schultz  wrote:

John,

On 11/2/22 12:44, John Dale (DB2DOM) wrote:

I'd like to continue to invest in Raspberry Pi, but also try to put
together a functional 32bit build of my software for those poor old
neglected closeted towers (really, poor things!).

I should be able to do it, from the looks of this.

Are you guys doing any kind of pruned down version of Tomcat or maybe
a configurable Tomcat that will only include some bare bones stuff
like request parsing, connection pooling, and (obviously) threading?


You might be surprised to learn that Tomcat is pretty stripped-down
already. What do you imagine that Tomcat is doing that is beyond what
you have listed above?


Isn't there still a lot of J2E code allowing deployment and processing
of J2E standards that aren't necessarily needed?  What else?


Well, it supports a few things that you may not use in your
application(s), such as WebSocket, asynchronous I/O, JSP/EL, and JASPIC.
Maybe you don't use JSPs, so you can throw-out the JSP and EL
components. But if you don't use them, they are a few inert kilobytes of
data on the disk. Same with JASPIC. Removing them would be more work
than simply ignoring them.

Tomcat 10.1 requires Java 11 because the specs it follows say that's the
minimum required version, for whatever reason.

The official Tomcat binary releases will be built using Java 11 and thus
they must be run by Java 11 or later.

But there's nothing stopping you from trying to use the source to build
a Java-8-compatible build of Tomcat 10.1. I don't think we are using any
source-level features of Java that actually require anything past Java
8. But if it vomits at runtime because something is missing because you
actually /do/ need Java 11, then we're gonna tell you "don't do that."


There are a few things that will break - and some of them are fairly
fundamental.

The simplest way to see what is going to break is to look at the
org.apache.tomcat.util.compat package. Then you need to look at the
JreNCompat classes that have been removed as a result of the increase in
minimum Java version. For 10.0.x to 10.1.x that is Jre9Compat.

If you want to run 10.1.x on Java 8, in theory you could revert the
commit that removed Jre9Compat but as Chris says you are very much on
your own in terms of support if things go wrong.

Mark

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




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



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



Re: Compatibility, 32 bit ..

2022-11-04 Thread Mark Thomas

On 03/11/2022 12:29, John Dale (DB2DOM) wrote:

Is Tomcat's HTTP/S processing libraries modular and portable?


That depends on how you define "HTTP/S processing libraries", "modular" 
and "portable".


Can you take then and use them with something else where you just need 
HTTP/S and no servlet API? Not easily.


Are they portable? Yes, they are as portable as Java is.

Are they modular? The classes are all in a single JAR but it is 
structured so it easy to extend with new implementations.


Tomcat uses JSSE for TLS. When using OpenSSL, it is wrapped so it looks 
like a JSSE implementation.


Mark





On 11/3/22, Mark Thomas  wrote:

On 02/11/2022 18:51, Christopher Schultz wrote:

John,

On 11/2/22 14:32, John Dale (DB2DOM) wrote:

On 11/2/22, Christopher Schultz  wrote:

John,

On 11/2/22 12:44, John Dale (DB2DOM) wrote:

I'd like to continue to invest in Raspberry Pi, but also try to put
together a functional 32bit build of my software for those poor old
neglected closeted towers (really, poor things!).

I should be able to do it, from the looks of this.

Are you guys doing any kind of pruned down version of Tomcat or maybe
a configurable Tomcat that will only include some bare bones stuff
like request parsing, connection pooling, and (obviously) threading?


You might be surprised to learn that Tomcat is pretty stripped-down
already. What do you imagine that Tomcat is doing that is beyond what
you have listed above?


Isn't there still a lot of J2E code allowing deployment and processing
of J2E standards that aren't necessarily needed?  What else?


Well, it supports a few things that you may not use in your
application(s), such as WebSocket, asynchronous I/O, JSP/EL, and JASPIC.
Maybe you don't use JSPs, so you can throw-out the JSP and EL
components. But if you don't use them, they are a few inert kilobytes of
data on the disk. Same with JASPIC. Removing them would be more work
than simply ignoring them.

Tomcat 10.1 requires Java 11 because the specs it follows say that's the
minimum required version, for whatever reason.

The official Tomcat binary releases will be built using Java 11 and thus
they must be run by Java 11 or later.

But there's nothing stopping you from trying to use the source to build
a Java-8-compatible build of Tomcat 10.1. I don't think we are using any
source-level features of Java that actually require anything past Java
8. But if it vomits at runtime because something is missing because you
actually /do/ need Java 11, then we're gonna tell you "don't do that."


There are a few things that will break - and some of them are fairly
fundamental.

The simplest way to see what is going to break is to look at the
org.apache.tomcat.util.compat package. Then you need to look at the
JreNCompat classes that have been removed as a result of the increase in
minimum Java version. For 10.0.x to 10.1.x that is Jre9Compat.

If you want to run 10.1.x on Java 8, in theory you could revert the
commit that removed Jre9Compat but as Chris says you are very much on
your own in terms of support if things go wrong.

Mark

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




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



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



Re: any plans for tomcat-native 1.2.36

2022-11-04 Thread Mark Thomas




On 03/11/2022 19:41, Усманов Азат Анварович wrote:

Hi Everyone!

I'm wondering if there are plans to release the next version of tomcat 
native 1.2 branch?I've scheduled a big server migration as well as 
tomcat upgrade 7.0.92 to -9.0.48   (everything seems to work  on 
test-enviroment) at $work on weekend(Oct 5th-6th) .I usually build 
openssl,tomcat-native  manually, currently using openssl 3.03 and tomcat 
native 1.2.33. it would be nice to upgrade both openssl and tomcat 
native at the same time during scheduled downtime. I did see a vote on a 
dev list for next release of 2.0 branch of tomcat native. any plans for 
tomcat -native 1.2.36?


No plans at all since there have been no changes to the code base since 
1.2.35.


Mark


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



Re: Compatibility, 32 bit ..

2022-11-03 Thread Mark Thomas

On 02/11/2022 18:51, Christopher Schultz wrote:

John,

On 11/2/22 14:32, John Dale (DB2DOM) wrote:

On 11/2/22, Christopher Schultz  wrote:

John,

On 11/2/22 12:44, John Dale (DB2DOM) wrote:

I'd like to continue to invest in Raspberry Pi, but also try to put
together a functional 32bit build of my software for those poor old
neglected closeted towers (really, poor things!).

I should be able to do it, from the looks of this.

Are you guys doing any kind of pruned down version of Tomcat or maybe
a configurable Tomcat that will only include some bare bones stuff
like request parsing, connection pooling, and (obviously) threading?


You might be surprised to learn that Tomcat is pretty stripped-down
already. What do you imagine that Tomcat is doing that is beyond what
you have listed above?


Isn't there still a lot of J2E code allowing deployment and processing
of J2E standards that aren't necessarily needed?  What else?


Well, it supports a few things that you may not use in your 
application(s), such as WebSocket, asynchronous I/O, JSP/EL, and JASPIC. 
Maybe you don't use JSPs, so you can throw-out the JSP and EL 
components. But if you don't use them, they are a few inert kilobytes of 
data on the disk. Same with JASPIC. Removing them would be more work 
than simply ignoring them.


Tomcat 10.1 requires Java 11 because the specs it follows say that's the 
minimum required version, for whatever reason.


The official Tomcat binary releases will be built using Java 11 and thus 
they must be run by Java 11 or later.


But there's nothing stopping you from trying to use the source to build 
a Java-8-compatible build of Tomcat 10.1. I don't think we are using any 
source-level features of Java that actually require anything past Java 
8. But if it vomits at runtime because something is missing because you 
actually /do/ need Java 11, then we're gonna tell you "don't do that."


There are a few things that will break - and some of them are fairly 
fundamental.


The simplest way to see what is going to break is to look at the 
org.apache.tomcat.util.compat package. Then you need to look at the 
JreNCompat classes that have been removed as a result of the increase in 
minimum Java version. For 10.0.x to 10.1.x that is Jre9Compat.


If you want to run 10.1.x on Java 8, in theory you could revert the 
commit that removed Jre9Compat but as Chris says you are very much on 
your own in terms of support if things go wrong.


Mark

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



[SECURITY] CVE-2022-42252 Apache Tomcat - Request Smuggling

2022-10-31 Thread Mark Thomas

CVE-2022-42252 Apache Tomcat - Request Smuggling

Severity: Low

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.1.0-M1 to 10.1.0
Apache Tomcat 10.0.0-M1 to 10.0.26
Apache Tomcat 9.0.0-M1 to 9.0.67
Apache Tomcat 8.5.0 to 8.5.52

Description:
If Tomcat was configured to ignore invalid HTTP headers via setting
rejectIllegalHeader to false (the default for 8.5.x only), Tomcat did 
not reject a request containing an invalid Content-Length header making 
a request smuggling attack  possible if Tomcat was located behind a 
reverse proxy that also failed to reject the request with the invalid 
header.



Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Ensure rejectIllegalHeader is set to true
- Upgrade to Apache Tomcat 10.1.1 or later
- Upgrade to Apache Tomcat 10.0.27 or later
- Upgrade to Apache Tomcat 9.0.68 or later
- Upgrade to Apache Tomcat 8.5.83 or later

Credit:
Thanks to Sam Shahsavar who discovered this issue and reported it to the 
Apache Tomcat security team.


History:
2022-10-31 Original advisory

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


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



Re: Tomcat/Java app timezone radomly changes during operation.

2022-10-27 Thread Mark Thomas

David,

I strongly suspect TimeZone.setDefault() is being called somewhere. I 
can confirm it isn't Tomcat calling it. If the problem was preceded by 
any application updates, I'd start looking there.


Mark


On 27/10/2022 16:31, David wrote:

Hi all,

   I've experienced an issue since the morning of the 21st that I'm
hoping to get some direction on for where to look.

   An app uses the date/time to set a timeout for a password reset.
This had been working fine for years and suddenly it failed.  A restart of
tomcat allowed it to work for a day, then 12 hours, then 5 hours, then 1 hr
and now is averaging a 10 minute or so working duration between tomcat
restarts.

 Changing the logging in the app showed that the issue is due to it
sending UTC to the DB while it is broken.  Restarting Tomcat results in CDT
being sent for a while until randomly it switches again.

RHEL 7.9, jvm 1.8.0_231-b11, Tomcat 9.0.29
ntp is on, chrony is syncing,  Java states correct time when queried
however unsure if it's JDK or JRE when targeted.  OS time is good.

When I redeploy the app, log timestamps for the app are in UTC as well
until restarting tomcat.   During the issue the log timestamp remains in
CDT as expected,  even though values passed are UTC.

I have explicitly defined the timezone in setenv.sh with no change in
behavior.

Any thoughts as what to investigate are greatly appreciated.

Thanks,
David



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



Re: Compatibility, 32 bit ..

2022-10-24 Thread Mark Thomas

On 24/10/2022 20:04, John Dale (DB2DOM) wrote:

Mark and Chris - do you guys have a favorite flavor of Linux that has
yielded good results?


I use Ubuntu for my various test environments and the servers I run at 
home. Stuff I know well (Tomcat, Java, etc) I tend to install manually 
rather than using the package manager.


Mark




Anyone else?

John


On 10/24/22, Mark Thomas  wrote:

On 24/10/2022 19:38, John Dale (DB2DOM) wrote:

Would Tomcat 10 work with Java 8?


No. Tomcat 10.1.x requires a minimum of Java 11.

Details of Tomcat versions, minimum Java versions and other useful
information:

https://tomcat.apache.org/whichversion.html

Mark




Thinking I might downgrade the JDK.


On 10/24/22, Mark Thomas  wrote:



On 24/10/2022 17:00, John Dale (DB2DOM) wrote:

Hi Mark;

Thanks for taking a look.

Below is more information.

Sincerely,

John Dale, MS MIS
Spearfish, SD USA

-

Tomcat version: 10.0.27 (unzipped, chmod 770 on catalina.sh before
cli: catalina.sh run)
java version: openjdk version "9-internal"
uname -m: i686
Ubuntu 18.0.4

First error in logs:
24-Oct-2022 09:52:24.411 SEVERE [main]
org.apache.tomcat.util.compat.Jre9Compat. Failed to create
references to Java 9 classes and methods
   java.lang.ClassNotFoundException: java.lang.ModuleLayer


You appear to have a broken JRE. That class should always be present in
Java 9 onwards.

Mark



   at
java.net.URLClassLoader.findClass(java.base@9-internal/URLClassLoader.java:384)
   at
java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:486)
   at
java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419)
   at
java.lang.Class.forName0(java.base@9-internal/Native
Method)
   at
java.lang.Class.forName(java.base@9-internal/Class.java:294)
   at
org.apache.tomcat.util.compat.Jre9Compat.(Jre9Compat.java:85)
   at
org.apache.tomcat.util.compat.JreCompat.(JreCompat.java:72)
   at
org.apache.catalina.core.JreMemoryLeakPreventionListener.lifecycleEvent(JreMemoryLeakPreventionListener.java:282)
   at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
   at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
   at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:135)
   at
org.apache.catalina.startup.Catalina.load(Catalina.java:747)
   at
org.apache.catalina.startup.Catalina.load(Catalina.java:769)
   at
sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-internal/Native
Method)
   at
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-internal/NativeMethodAccessorImpl.java:62)
   at
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-internal/DelegatingMethodAccessorImpl.java:43)
   at
java.lang.reflect.Method.invoke(java.base@9-internal/Method.java:531)
   at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:305)
   at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)



On 10/24/22, Mark Thomas  wrote:

On 24/10/2022 02:01, John Dale (DB2DOM) wrote:

Hi Everyone;

I've had a few requests to refurbish some old 32 bit dell towers.

So, I'm throwing ubuntu on them and bringing up a
MySQL->DB2DOM->Tomcat
stack.

Unfortunately, Tomcat doesn't want to start with openjdk 9 that is
packaged with 32 bit ubuntu.


Tomcat works happily with 32-bit and 64-bit Java.


Can someone give me a pointer to what works best?

Perhaps if you told us what Tomcat version you were using and showed
us
what the error message was we'd be able to provide slightly more
advice
than "You are doing something wrong. Don't do that".

Mark



Also, any heads up about missing libs or other nuances would also be
appreciated (jax mods were most painful).

Sincerely,

John Dale, MS MIS
Spearfish, SD USA

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



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




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



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




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

Re: Compatibility, 32 bit ..

2022-10-24 Thread Mark Thomas

On 24/10/2022 19:38, John Dale (DB2DOM) wrote:

Would Tomcat 10 work with Java 8?


No. Tomcat 10.1.x requires a minimum of Java 11.

Details of Tomcat versions, minimum Java versions and other useful 
information:


https://tomcat.apache.org/whichversion.html

Mark




Thinking I might downgrade the JDK.


On 10/24/22, Mark Thomas  wrote:



On 24/10/2022 17:00, John Dale (DB2DOM) wrote:

Hi Mark;

Thanks for taking a look.

Below is more information.

Sincerely,

John Dale, MS MIS
Spearfish, SD USA

-

Tomcat version: 10.0.27 (unzipped, chmod 770 on catalina.sh before
cli: catalina.sh run)
java version: openjdk version "9-internal"
uname -m: i686
Ubuntu 18.0.4

First error in logs:
24-Oct-2022 09:52:24.411 SEVERE [main]
org.apache.tomcat.util.compat.Jre9Compat. Failed to create
references to Java 9 classes and methods
  java.lang.ClassNotFoundException: java.lang.ModuleLayer


You appear to have a broken JRE. That class should always be present in
Java 9 onwards.

Mark



  at
java.net.URLClassLoader.findClass(java.base@9-internal/URLClassLoader.java:384)
  at
java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:486)
  at
java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419)
  at java.lang.Class.forName0(java.base@9-internal/Native
Method)
  at
java.lang.Class.forName(java.base@9-internal/Class.java:294)
  at
org.apache.tomcat.util.compat.Jre9Compat.(Jre9Compat.java:85)
  at
org.apache.tomcat.util.compat.JreCompat.(JreCompat.java:72)
  at
org.apache.catalina.core.JreMemoryLeakPreventionListener.lifecycleEvent(JreMemoryLeakPreventionListener.java:282)
  at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
  at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
  at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:135)
  at
org.apache.catalina.startup.Catalina.load(Catalina.java:747)
  at
org.apache.catalina.startup.Catalina.load(Catalina.java:769)
  at
sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-internal/Native
Method)
  at
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-internal/NativeMethodAccessorImpl.java:62)
  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-internal/DelegatingMethodAccessorImpl.java:43)
  at
java.lang.reflect.Method.invoke(java.base@9-internal/Method.java:531)
  at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:305)
  at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)



On 10/24/22, Mark Thomas  wrote:

On 24/10/2022 02:01, John Dale (DB2DOM) wrote:

Hi Everyone;

I've had a few requests to refurbish some old 32 bit dell towers.

So, I'm throwing ubuntu on them and bringing up a MySQL->DB2DOM->Tomcat
stack.

Unfortunately, Tomcat doesn't want to start with openjdk 9 that is
packaged with 32 bit ubuntu.


Tomcat works happily with 32-bit and 64-bit Java.


Can someone give me a pointer to what works best?

Perhaps if you told us what Tomcat version you were using and showed us
what the error message was we'd be able to provide slightly more advice
than "You are doing something wrong. Don't do that".

Mark



Also, any heads up about missing libs or other nuances would also be
appreciated (jax mods were most painful).

Sincerely,

John Dale, MS MIS
Spearfish, SD USA

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



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




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



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




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



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



Re: Compatibility, 32 bit ..

2022-10-24 Thread Mark Thomas




On 24/10/2022 17:00, John Dale (DB2DOM) wrote:

Hi Mark;

Thanks for taking a look.

Below is more information.

Sincerely,

John Dale, MS MIS
Spearfish, SD USA

-

Tomcat version: 10.0.27 (unzipped, chmod 770 on catalina.sh before
cli: catalina.sh run)
java version: openjdk version "9-internal"
uname -m: i686
Ubuntu 18.0.4

First error in logs:
24-Oct-2022 09:52:24.411 SEVERE [main]
org.apache.tomcat.util.compat.Jre9Compat. Failed to create
references to Java 9 classes and methods
 java.lang.ClassNotFoundException: java.lang.ModuleLayer


You appear to have a broken JRE. That class should always be present in 
Java 9 onwards.


Mark



 at
java.net.URLClassLoader.findClass(java.base@9-internal/URLClassLoader.java:384)
 at
java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:486)
 at
java.lang.ClassLoader.loadClass(java.base@9-internal/ClassLoader.java:419)
 at java.lang.Class.forName0(java.base@9-internal/Native Method)
 at java.lang.Class.forName(java.base@9-internal/Class.java:294)
 at
org.apache.tomcat.util.compat.Jre9Compat.(Jre9Compat.java:85)
 at
org.apache.tomcat.util.compat.JreCompat.(JreCompat.java:72)
 at
org.apache.catalina.core.JreMemoryLeakPreventionListener.lifecycleEvent(JreMemoryLeakPreventionListener.java:282)
 at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
 at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
 at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:135)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:747)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:769)
 at
sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-internal/Native
Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-internal/NativeMethodAccessorImpl.java:62)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-internal/DelegatingMethodAccessorImpl.java:43)
 at
java.lang.reflect.Method.invoke(java.base@9-internal/Method.java:531)
 at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:305)
 at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)



On 10/24/22, Mark Thomas  wrote:

On 24/10/2022 02:01, John Dale (DB2DOM) wrote:

Hi Everyone;

I've had a few requests to refurbish some old 32 bit dell towers.

So, I'm throwing ubuntu on them and bringing up a MySQL->DB2DOM->Tomcat
stack.

Unfortunately, Tomcat doesn't want to start with openjdk 9 that is
packaged with 32 bit ubuntu.


Tomcat works happily with 32-bit and 64-bit Java.


Can someone give me a pointer to what works best?

Perhaps if you told us what Tomcat version you were using and showed us
what the error message was we'd be able to provide slightly more advice
than "You are doing something wrong. Don't do that".

Mark



Also, any heads up about missing libs or other nuances would also be
appreciated (jax mods were most painful).

Sincerely,

John Dale, MS MIS
Spearfish, SD USA

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



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




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



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



Re: Apache Tomcat started, but error 404

2022-10-24 Thread Mark Thomas

On 24/10/2022 08:01, Strib wrote:

Hello and thank you,

The error message reads as follows:
'org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/APPWARFILE]]'


And the rest of that message? What does the stack trace show?

There may also be earlier errors in the logs that are relevant.

Mark



There are two app files trying to start, and both are getting the same
error. The weird part is, these app packages were not touched since before
the summer. Server patches have happened since, but this is the first month
where Tomcat is doing this So, two key notes:
1: app packages have not been changed.
2: hot and warm servers have been patched, but only hot servers received
this Tomcat error. This is the first month I've seen Tomcat not start
properly, which makes me believe it's Tomcat.
Also, just FYI, this is for Tomcat 8.

Very respectfully,
Darious


On Mon, Oct 24, 2022 at 3:28 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:


Hello,


-Ursprüngliche Nachricht-
Von: Strib 
Gesendet: Montag, 24. Oktober 2022 08:10
An: users@tomcat.apache.org
Betreff: Apache Tomcat started, but error 404

Hello, trying to see if anyone else had this issue. After a reboot of

hot and

warm servers, my sites using Tomcat throws the error 404 only on the hot
servers. I've stopped and started Tomcat services, nothing. In the logs,

there

were 2 errors. One was Catalina. But even though the error happened on

hot

and warm servers, warm sites are still working, so I'm thinking that's

not it. The

other error on the hot servers says startup error. Is it just luck of

the draw, of

starting/stopping Tomcat services?
Is it something else, entirely? Frustrating that Tomcat does not have a

UI to

make this easier. Thanks in advance.

Very respectfully,
Darious


Could you past the error message about startup issue?
404 sounds like your application failed to start but Tomcat is running.
So it might be an issue with the application.
In the log files there are usually information about the reason.

Greetings, Thomas





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



Re: Compatibility, 32 bit ..

2022-10-24 Thread Mark Thomas

On 24/10/2022 02:01, John Dale (DB2DOM) wrote:

Hi Everyone;

I've had a few requests to refurbish some old 32 bit dell towers.

So, I'm throwing ubuntu on them and bringing up a MySQL->DB2DOM->Tomcat stack.

Unfortunately, Tomcat doesn't want to start with openjdk 9 that is
packaged with 32 bit ubuntu.


Tomcat works happily with 32-bit and 64-bit Java.

Can someone give me a pointer to what works best? 
Perhaps if you told us what Tomcat version you were using and showed us 
what the error message was we'd be able to provide slightly more advice 
than "You are doing something wrong. Don't do that".


Mark



Also, any heads up about missing libs or other nuances would also be
appreciated (jax mods were most painful).

Sincerely,

John Dale, MS MIS
Spearfish, SD USA

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



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



Re: Tomcat 10.1.1 error starting

2022-10-20 Thread Mark Thomas

On 20/10/2022 18:03, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, thanks Peter. I looked at the running.txt to see if it mentioned a Java 
version minimum and it stated Java 8, so it confused me. I'll try with Java 11.


That is an error. I've fixed it for the next release.

Mark




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

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

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

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


-Original Message-
From: Peter Kreuser 
Sent: Thursday, October 20, 2022 12:00 PM
To: Tomcat Users List 
Subject: Re: Tomcat 10.1.1 error starting

Jon,




Am 20.10.2022 um 18:57 schrieb jonmcalexan...@wellsfargo.com.invalid:

Good morning,

I am getting the following error when trying to start a very generic setup of

Tomcat 10.1.1 on Windows Server 2019.


Error: A JNI error has occurred, please check your installation and
try again Exception in thread "main"

java.lang.UnsupportedClassVersionError:
org/apache/catalina/startup/Bootstrap has been compiled by a more recent
version of the Java Runtime (class file version 55.0), this version of the Java
Runtime only recognizes class file versions up to 52.0

at


Looks like you are running Tomcat on an older Java, that the app was
compiled with...

Need to lookup the exact class versions, but like:

Compiled with jdk13 and running on java 11.

HTH

Peter


java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at

java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:355)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at


sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601)


Is there a minimum version of Java 8 that is required?

Thanks,

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

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

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



jonmcalexan...@wellsfargo.com

This message may contain confidential and/or privileged information. If you

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




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



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



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



Re: AJP Connector is configured with secretRequired="true" but the secret attribute is either null

2022-10-20 Thread Mark Thomas

On 20/10/2022 17:59, Paquin, Brian wrote:

Hello,

In some cases, I use mod_jk and I am able to have Apache send a “secret” to my 
Tomcat Connector.
But in other cases, I don’t have a front end – I just use Tomcat 9.0.68 (with 
Tomcat Native 1.2.35) to host.
In the past, I did not need to provide a “secret”, but now it appears I do 
since I get the following error in Catalina.out:


java.lang.IllegalArgumentException: The AJP Connector is configured with 
secretRequired="true" but the secret attribute is either null or "". This 
combination is not valid.

I have modified the connector in my server.xml for Tomcat to include an address 
(server IP) and secret, or try secretRequired=”false”, but the error still 
persists.
Am I correct that I also need to add the “secret” to Tomcat Native?


No. That is for AJP connectors only.


If yes, where do I add it?


N/A.


If no, what else should I do?


Show us all the Connector elements in you server.xml file. Mask any 
sensitive information.


Mark

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



Re: Tomcat 10.1.1 error starting

2022-10-20 Thread Mark Thomas



On 20/10/2022 17:56, jonmcalexan...@wellsfargo.com.INVALID wrote:

Good morning,

I am getting the following error when trying to start a very generic setup of 
Tomcat 10.1.1 on Windows Server 2019.

Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: 
org/apache/catalina/startup/Bootstrap has been compiled by a more recent version of the 
Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes 
class file versions up to 52.0





Is there a minimum version of Java 8 that is required?


Tomcat 10.1.x requires Java 11 as a minimum.

Mark


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



Re: BIO connector vs NIO connector

2022-10-20 Thread Mark Thomas

On 20/10/2022 10:33, Terry ST SY/OGCIO wrote:

Hi ,

Check on the major changes on Tomcat 7 to Tomcat 9. (One of the major change we 
initially spotted is the BIO connector used in Tomcat 7 for connector setup was 
removed in Tomcat 9: 
https://tomcat.apache.org/migration-9.html#BIO_connector_removed)

May I know the major difference on BIO connector and NIO connector ?


https://tomcat.apache.org/tomcat-8.0-doc/config/http.html#Connector_Comparison

Note also that the APR/native Connector has been deprecated and removed 
in Tomcat 10.1.x onwards.



if NIO have better performance, where can I get the bench mark comparison 
report ?


The raw performance difference for a single connection is marginal. You 
could probably construct a test that demonstrates either is a few 
percentage points "better" than the other.


The key difference is scalability. Look at the descriptions for 
maxConnections, maxThreads and disableKeepAlivePercentage.


With default settings, NIO can support orders of magnitude more 
connections using HTTP keep-alive. That should lead to performance 
benefits in terms of reduced connection set-up time - i.e. lower latency.


Mark

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



Re: It seems Tomcat shares libraries between web applications

2022-10-13 Thread Mark Thomas

On 13/10/2022 14:17, Artur Swat wrote:

How app Y can get a library from app X? Is tomcat\temp shared between web
applications?


If you define a DataSource as a global resource then the associated JDBC 
driver has to be loaded by the Common class loader. That makes it 
visible to all web applications.


Mark

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



[ANN] Apache Tomcat 10.1.1 available

2022-10-11 Thread Mark Thomas

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

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

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


The notable changes compared to 10.1.0 include:

- Fix bug 66277, a refactoring regression that broke JSP includes
  amongst other functionality

- Fix unexpected timeouts that may appear as client disconnections when
  using HTTP/2 and NIO2

- Update to Eclipse JDT compiler 4.23

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

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

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

Enjoy!

- The Apache Tomcat team

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



Re: Cannot find annotation method 'value()' in type 'aQute.bnd.annotation.spi.ServiceConsumer'

2022-10-11 Thread Mark Thomas
esolve some of those additional warnings. In this instance, you need 
to add the bnd dependency.


To put this in perspective, that JAR has been using that annotation for 
just over two years.


Maven Central stats show about 7.6 million downloads last month alone of 
the tomcat-embed-core JAR.


Your is the only question ever received about this warning.

The cost of all those users being required to download a bnd jar for no 
benefit to them far outweighs the cost of a single user being required 
to add a dependency to their pom.


Mark




Garret

On 10/11/2022 1:34 AM, Mark Thomas wrote:

On 10/10/2022 13:34, Garret Wilson wrote:

On 10/10/2022 12:14 AM, Mark Thomas wrote:

…

That is a fairly old version. You should upgrade to the latest 
version first.


I certainly will. I first went through a long list of linting 
problems in the project; this was one of the things left over. I 
wanted to understand it more.



If you want to fix the warning, those are not the correct dependencies.

If you want the exact dependencies used with 9.0.50 then you can 
find them from the source code:

…


You want
bnd (not bndlib) 5.3.0
OSGi annotations 1.1.0



That's super helpful. I'll go look for those.

But could someone give a 1–3 sentence overview of what these 
libraries are and why Tomcat uses them? Or is there a wiki page 
explaining that already?


The bnd library is used to generate JPMS and OSGI metadata for the 
Tomcat JARs. Most of the metadata is generated from scanning the JARs 
but where code uses the ServiceLoader, the annotation is required so 
that bnd can generate the correct service dependencies.


The annotation is only used by bnd during the build. It is not used at 
runtime.


Mark

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



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



[ANN] Apache Tomcat 8.5.83 available

2022-10-11 Thread Mark Thomas

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

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

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

- Add support for authenticating WebSocket clients with an HTTP forward
  proxy when establishing a connection to a WebSocket endpoint via a
  forward proxy that requires authentication. Based on a patch provided
  by Joe Mokos.

- Various fixes for edge case bugs in EL processing

- Enforce the requirement of RFC 7230 onwards that a request with a
  malformed content-length header should always be rejected with a 400
  response.

Along with lots of other bug fixes and improvements.

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


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

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

Enjoy!

- The Apache Tomcat team

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



Re: Cannot find annotation method 'value()' in type 'aQute.bnd.annotation.spi.ServiceConsumer'

2022-10-11 Thread Mark Thomas

On 10/10/2022 13:34, Garret Wilson wrote:

On 10/10/2022 12:14 AM, Mark Thomas wrote:

…

That is a fairly old version. You should upgrade to the latest version 
first.


I certainly will. I first went through a long list of linting problems 
in the project; this was one of the things left over. I wanted to 
understand it more.



If you want to fix the warning, those are not the correct dependencies.

If you want the exact dependencies used with 9.0.50 then you can find 
them from the source code:

…


You want
bnd (not bndlib) 5.3.0
OSGi annotations 1.1.0



That's super helpful. I'll go look for those.

But could someone give a 1–3 sentence overview of what these libraries 
are and why Tomcat uses them? Or is there a wiki page explaining that 
already?


The bnd library is used to generate JPMS and OSGI metadata for the 
Tomcat JARs. Most of the metadata is generated from scanning the JARs 
but where code uses the ServiceLoader, the annotation is required so 
that bnd can generate the correct service dependencies.


The annotation is only used by bnd during the build. It is not used at 
runtime.


Mark

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



[ANN] Apache Tomcat 10.0.27 available

2022-10-10 Thread Mark Thomas

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

This release is targeted at Jakarta EE 9.

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


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

The notable changes compared to 10.0.26 include:

- Fix bug 66277, a refactoring regression that broke JSP includes
  amongst other functionality

- Fix unexpected timeouts that may appear as client disconnections when
  using HTTP/2 and NIO2

- Enforce the requirement of RFC 7230 onwards that a request with a
  malformed content-length header should always be rejected with a 400
  response.

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

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

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

Enjoy!

- The Apache Tomcat team

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



Re: Cannot find annotation method 'value()' in type 'aQute.bnd.annotation.spi.ServiceConsumer'

2022-10-10 Thread Mark Thomas

On 09/10/2022 20:50, Garret Wilson wrote:

I have a Java 11 project embedding Tomcat:

```xml

   org.apache.tomcat.embed
   tomcat-embed-core
   9.0.50

```


That is a fairly old version. You should upgrade to the latest version 
first.


The Tomcat-specific code is in a subproject with only two classes. When 
I compile using Maven 3.8.6 and Java 17 using `-Xlint:all`, I see the 
following warning for that subproject:


 > [WARNING] Cannot find annotation method 'value()' in type
 > 'aQute.bnd.annotation.spi.ServiceConsumer':
 > class file for aQute.bnd.annotation.spi.ServiceConsumer not found


That is only a warning. The annotation isn't used at run time. You can 
safely ignore the warning.


As mentioned this only seems to happen with -`Xlint:all` turned on for 
`javac`:


That is as expected.



Doing a bit of searching brings up similar (but not exact) things, such 
as [Lombok Issue 
#2145](https://github.com/projectlombok/lombok/issues/2145), which hints 
that I may need to add some sort of extra dependency such as 
`biz.aQute.bnd:bndlib` or `org.osgi:osgi.annotation`.


But I've tried this and and I still get the warning:

```xml

   biz.aQute.bnd
   bndlib
   2.4.0

```

I also tried this; no difference:

```xml

   org.osgi
   osgi.annotation
   7.0.0

```


If you want to fix the warning, those are not the correct dependencies.

If you want the exact dependencies used with 9.0.50 then you can find 
them from the source code:


Github project:
https://github.com/apache/tomcat

9.0.50 tag:
https://github.com/apache/tomcat/tree/9.0.50

Default build properties:
https://github.com/apache/tomcat/blob/9.0.50/build.properties.default

You want
bnd (not bndlib) 5.3.0
OSGi annotations 1.1.0

If you use the latest version of bnd you won't need the OSGi annotation 
dependency.


I also [asked on Stack Overflow](https://stackoverflow.com/q/74000505). 
No answers so far.


I filed [Bug 
66299](https://bz.apache.org/bugzilla/show_bug.cgi?id=66299] because I 
imagine that the Tomcat artifact isn't including some necessary 
dependency. That bug got closed because I'm supposed to ask here on this 
list first; nevertheless, including a Tomcat artifact should not result 
a warning regarding some other dependency I've never heard of and didn't 
refer to, so in any case this is incorrect behavior, and needs to be fixed.


No, this is not incorrect behaviour and it does not need to be fixed.

Still I'd like to find out what's going on—maybe I can help you fix it. 


There is nothing to fix.


Where is this error coming from, and what does it mean?


It means that the compiler has found a reference to a annotation that it 
can't resolve. Normally, it would just ignore it but because Xlint:all 
is configured then a warning is issued.


I don't have any 
`@ServiceConsumer` annotation in my source code, and I couldn't find any 
in the Tomcat classes I'm extending, either.


It is present in org.apache.juli.logging.LogFactory which is likely one 
of the classes your source code indirectly depends on since nearly all 
Tomcat classes reference it.


Shouldn't the 
`org.apache.tomcat.embed:tomcat-embed-core` dependency contain 
everything I need (either in the artifact or via a transitive 
dependency) just to build a project that references the Tomcat classes? 


That JAR does contain everythign you need. Nothing is stopping you 
building against the Tomcat embedded JAR. Neither will you see any 
runtime errors.



What is missing here?


Nothing.

Mark

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



Re: About granting permissions to Tomcat JVM

2022-10-08 Thread Mark Thomas

On 08/10/2022 17:36, Martin Moore wrote:

Hello,

I am facing a problem using Tomcat V8 with my J2ee app that deletes (using
file.delete() Java 8) a file from disk (Windows). The file is actually
deleting only on application level meaning that the application does not
see the file anymore but if i open the folder i still see the file which is
then locked by Java process. I only get the file to be removed physically
when i close the Tomcat instance.

Does this problem relate to permissions in catalina.policy ?


Unlikely.

Are you using a SecurityManager?


How to solve this?


Where, exactly, are you storing these files? Where, exactly, are 
CATALINA_HOME and CATALINA_BASE?


Mark

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



Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

2022-10-07 Thread Mark Thomas

On 07/10/2022 19:47, Bhavesh Mistry wrote:

Hi Mark,

Thank you for your quick response.  Your proposed solution works by
removing the transport-guarantee element.  Another quick question, I have
Connection has a property called allowTrace method. Is it possible to
configure TOMCAT Connector to disallow TRACE,OPTIONS,HEAD,CONNECT rather
than having custom logic at the application level?


No.


 Do you think it good idea to have Connector Config which method to allow and 
disallow?


No.

I don't think it is a good idea to have an option to disable TRACE at 
the connector level. I'd be quite happy to remove that feature but I'm 
fairly sure I would not be able to get consensus to do that.


My understanding is that TRACE got its poor reputation due to a 
misbehaving browser. Rather than pressure the browser vendor to fix 
their broken browser, the security community decided to pressure the 
server community to disable the functionality the browser didn't handle 
properly. That just seems backwards to me no matter how big the 
browser's market share might have been at the time and how reluctant to 
change the vendor was.


CONNECT returns 405 by default in a Servlet container and none of TRACE, 
OPTIONS or HEAD are inherently unsafe.


Mark




Thanks,

Bhavesh

On Fri, Oct 7, 2022 at 10:59 AM Mark Thomas  wrote:


On 07/10/2022 18:09, Bhavesh Mistry wrote:

Hi Tomcat Team,

We have a unique situation.  We wanted to block ALL *OPTIONALS* HTTP

method

on port 80 and 443.

We have connector definitions as follows:


  
  -->
  -->
  
relaxedQueryChars="[\\]^`{|}"

 address="${tomcat.address}" minSpareThreads="100"
   maxThreads="200" SSLEnabled="true"
 scheme="https" secure="true" maxSwallowSize="-1"
maxPostSize="-1">
  
className="org.apache.coyote.http2.Http2Protocol"

readTimeout="5" streamReadTimeout ="-1" streamWriteTimeout="-1"
  overheadContinuationThreshold="0" overheadDataThreshold="0"
overheadWindowUpdateThreshold="0"/>

  

and we have an application filter to block and return 405.  This works

for

HTTPS port 443.  But request going to HTTP port 80 always get redirected
regardless of the method.

curl -i -k -X OPTIONS http://10.43.243.8/versa/
*HTTP/1.1 302*
Cache-Control: private
Location: https://10.43.243.8/versa/
Content-Length: 0
Date: Fri, 07 Oct 2022 16:58:27 GMT
Server: Versa Director

curl -i -k -X OPTIONS https://10.43.243.8/versa/
*HTTP/2 405*
cache-control: private
content-length: 0
date: Fri, 07 Oct 2022 16:58:51 GMT

We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat
internally  (via connector) redirects requests without application code.
How can I achieve blocking OPTIONS, TRACE, and CONNECT  HTTP methods on
port 80 while redirect is ON for the connector?

Any pointers or help is greatly appreciated.


Tomcat only redirects http to https as the result of an application
defined transport-guarantee element in web.xml.

Security constraints get processed before Filters.

You can't change the either of the above.

What you could do, is remove the transport-guarantee from web.xml and
perform the http to https redirect in your Filter. Then you'd have the
option to return 405 instead of the redirect.

Mark

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






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



Re: Tomcat Redirect Port 80 to 443 and Block OPTIONS HTTP Method

2022-10-07 Thread Mark Thomas

On 07/10/2022 18:09, Bhavesh Mistry wrote:

Hi Tomcat Team,

We have a unique situation.  We wanted to block ALL *OPTIONALS* HTTP method
on port 80 and 443.

We have connector definitions as follows:


 
 -->
 -->
 
 

 

and we have an application filter to block and return 405.  This works for
HTTPS port 443.  But request going to HTTP port 80 always get redirected
regardless of the method.

curl -i -k -X OPTIONS http://10.43.243.8/versa/
*HTTP/1.1 302*
Cache-Control: private
Location: https://10.43.243.8/versa/
Content-Length: 0
Date: Fri, 07 Oct 2022 16:58:27 GMT
Server: Versa Director

curl -i -k -X OPTIONS https://10.43.243.8/versa/
*HTTP/2 405*
cache-control: private
content-length: 0
date: Fri, 07 Oct 2022 16:58:51 GMT

We wanted to block OPTIONS on port 80 as well, it seems to me that tomcat
internally  (via connector) redirects requests without application code.
How can I achieve blocking OPTIONS, TRACE, and CONNECT  HTTP methods on
port 80 while redirect is ON for the connector?

Any pointers or help is greatly appreciated.


Tomcat only redirects http to https as the result of an application 
defined transport-guarantee element in web.xml.


Security constraints get processed before Filters.

You can't change the either of the above.

What you could do, is remove the transport-guarantee from web.xml and 
perform the http to https redirect in your Filter. Then you'd have the 
option to return 405 instead of the redirect.


Mark

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



[ANN] Apache Tomcat 9.0.68 available

2022-10-07 Thread Mark Thomas

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

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

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

- Fix bug 66277, a refactoring regression that broke JSP includes
  amongst other functionality

- Fix unexpected timeouts that may appear as client disconnections when
  using HTTP/2 and NIO2

- Enforce the requirement of RFC 7230 onwards that a request with a
  malformed content-length header should always be rejected with a 400
  response.

Along with lots of other bug fixes and improvements.

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


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

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

Enjoy!

- The Apache Tomcat team

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



Re: Question about upgrade from Tomcat 7 to Tomcat 9.0.67

2022-10-05 Thread Mark Thomas




On 05/10/2022 09:17, Terry ST SY/OGCIO wrote:

Hi ,

we would like to upgrade Tomcat 7 to Tomcat 9.0.67.

Check on the major changes on Tomcat 7 to Tomcat 9. (One of the major change we 
initially spotted is the BIO connector used in Tomcat 7 for connector setup was 
removed in Tomcat 9: 
https://tomcat.apache.org/migration-9.html#BIO_connector_removed)

For your reference, Http11Protocol was used in Tomcat 7, but since Tomcat 9 
removed it, we tried to Http11NioProtocol with same parameters in the tomcat 
config in “conf/server.xml. Is it a proper method for migrate the BIO connector 
( Tomcat 7 ) to NIO connector ( Tomcat 9 ) ?


Generally, I'd recommend the following:

1. Review the server.xml you use for Tomcat 7 and note each deviation
   from the defaults
2. Start with the default server.xml for 9.0.x and for each of the
   additional/changed settings noted in step 1, determine if you still
   need to apply it in Tomcat 9.

The HttpNioProtocol is the default in 9.0.x. Generally, the settings 
will translate from 7.0.x but you should still review them to ensure 
they remain appropriate for your environment.


Mark

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



Re: Context Name replacement variable for conf/context.xml

2022-10-03 Thread Mark Thomas

Chris,

I think you misunderstood the requirement.

My reading of the OP request is that they want to add a standard 
 element to conf/context.xml so each web application uses 
the same custom session manager implementation. They want to be able to 
configure that session manager with at least one attribute that depends 
on the context name/path so that they can maintain separation of session 
manager instances between web applications.


We have something like this for JULI: ${classloader.webappName}.

There isn't anything that can currently do this for conf/context.xml but 
it might be possible to leverage WebappProperties that JULI uses to 
implement a new PropertySource. I haven't looked. I suggest created an 
enhancement request for this feature in Bugzilla.


Mark


On 03/10/2022 03:14, Christopher Schultz wrote:


Kok Hoor,

On 10/1/22 10:20, Chew Kok Hoor wrote:

I would like to configure $CATALINA_BASE/conf/context.xml to set up
a Manager


Don't do this.

but would like to add the context name as one of the parameters to the 
manager (keyPrefix).


It's much easier to copy webapps/manager/META-INF/context.xml to 
CATALINA_BASE/conf/Catalina/localhost/keyPrefix-manager.xml and allow it 
so auto-deploy to that context-path.


Is there a variable or a list of variables I can use for this purpose? 
As using environment or java defined variables will not fit

this use case.
If you can't use system properties or environment variables, then what 
options do you actually have?


-chris

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



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



Re: tomcat 9.0.67 not supported

2022-09-30 Thread Mark Thomas

On 30/09/2022 12:54, zhta...@163.com wrote:

Hi,
 I used the latest version of tomcat (9.0.67) to deploy jsp applications. I found 
that thetag is not supported, but 9.0.65 does. Is it no longer 
supported in later versions?


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

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



Re: [ANN] Apache Tomcat 9.0.67 available

2022-09-29 Thread Mark Thomas

Yes. Both 10.0.26 and 10.1.0 are also affected.

Mark

On 29/09/2022 16:35, jonmcalexan...@wellsfargo.com.INVALID wrote:

Does this also affect the 10.1.0 (stable) version?

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

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

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

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



-Original Message-
From: Rémy Maucherat 
Sent: Thursday, September 29, 2022 3:50 AM
To: Tomcat Users List 
Subject: Re: [ANN] Apache Tomcat 9.0.67 available
Importance: High

On Thu, Sep 29, 2022 at 10:06 AM Greg Huber 
wrote:


Hello,

I am testing this release and are getting lots of these type of random
errors :

<%@include file="../widgets/lazyload.jsp" %>


Caused by: org.apache.jasper.JasperException:
/WEB-INF/jsps/core/listMe.jsp (line: [91], column: [2]) JSP file
[../widgets/lazyload.jsp] not found

at


org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandle
r.java:41)

  at


org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:29
2)

  at


org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:98)

  at


org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:349)

  at
org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:384)
  at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:485)
  at
org.apache.jasper.compiler.Parser.parseFileDirectives(Parser.java:1802)
  at org.apache.jasper.compiler.Parser.parse(Parser.java:141)
  at


org.apache.jasper.compiler.ParserController.doParse(ParserController.java:2
45)

  at


org.apache.jasper.compiler.ParserController.parseDirectives(ParserControlle
r.java:128)

  at

org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:202)

  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:391)
  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:367)
  at org.apache.jasper.compiler.Compiler.compile(Compiler.java:351)
  at


org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.ja
va:605)

  at


org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.jav
a:399)

  at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
  at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:779)
  at


org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFi
lterChain.java:227)

  at


org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai
n.java:162)

  at


org.apache.logging.log4j.web.Log4jServletFilter.doFilter(Log4jServletFilter.ja
va:64)

  at


org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFi
lterChain.java:189)

  at


org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChai
n.java:162)

  at


org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher
.java:711)

  at


org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatc
her.java:578)

  at


org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatche
r.java:517)

  at


org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.jav
a:994)

  at


org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:
485)

  at
org.apache.tiles.request.jsp.JspRequest.doInclude(JspRequest.java:123)
  ... 213 more

If I go back to 9.0.65 everything is ok.

Have there been any changes?


https://urldefense.com/v3/__https://bz.apache.org/bugzilla/show_bug.cgi?
id=66277__;!!F9svGWnIaVPGSwU!oe-
ntt3a2h3oEQ2Navb1EiIdPfGqEhBY3rClXne5jyqdnB0CtJuYud5wtzTXQPN2hNz
eStrpVfhHXgJL6PqF$
Discovered shortly after the release announcement. It is expected there will
be a .68 release with the fix next week.

Rémy


Cheers Greg


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



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



-
To unsubscribe, e-mail: 

Re: AW: Slow startup first time after reboot

2022-09-29 Thread Mark Thomas

On 29/09/2022 04:05, Jerry Malcolm wrote:
Hi, Mark, Thanks for the info. Getting several thread dumps is not going 
to be easy in this specific situation.  This problem only occurs on 
initial boot up of a newly-imaged linux EC2 which is built and launched 
automatically by the AWS autoscaling service.  By the time i can see 
that an image has been created and launched, get the newly assigned IP 
address from AWS, then go through the initialization of a puTTY session, 
then get the PID for tomcat, I'm pretty much out of time to try to get 
meaningful thread dumps. I have no doubt that the thread dump might tell 
us something.  But short of some major restructuring and special 
scaffolding to obtain useful dumps, I want to exhaust all other 
alternatives to find the problem prior to going down that hole.


In your initial post you stated you also observed the problem in your 
local Windows development environment. Take the thread dumps there.


Mark




     1) Are there any finer log levels I can turn on to get more data 
for initializing webapps?


     2) In general, what occurs on init of a webapp?  I know it does tld 
scanning of jar files.  But I'm not getting tld scan warnings. And any 
tld scans that do happen occur on every TC boot, right?


     3) Are the datasource pools being initialized such that there could 
be some database timeout wait occurring?   (Not sure why there would be 
db timeouts, though... the db is up and running and not approaching 
connection limits)


     4) Does it load/cache every jar file in the lib folder on init

     5) Does it perhaps precompile all of the JSPs and cache them 
somewhere that the jvm might still have them on a TC reboot?  When it's 
doing slow-load, the time varies between 13 and 19 seconds, and the time 
appears to be correlated to the number of JSPs in the web app.


I know I'm just grasping at straws.  But hopefully I can figure out 
something that is causing this super long load time without having to 
figure out the thread-dump on system boot procedure.


Thanks again.

Jerry

On 9/28/2022 11:33 AM, Mark Thomas wrote:
Lots of ways. I'd try starting with the jstack tool which should be 
provided as part of the JDK you are using.


Mark


On 28/09/2022 17:16, Jerry Malcolm wrote:
Thanks, Mark, I'm not familiar with how to take a thread dump in TC. 
Can you point me to documentation on that?


Jerry


On 9/28/2022 2:56 AM, Mark Thomas wrote:
Take three thread dumps 5s apart during the slowness and then diff 
them to see what is moving and what is not.


Mark


On 28/09/2022 07:30, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,

could the underlying hardware cause the delay?
Maybe the OS has cached some data and don’t need to read it from 
disk again?


Maybe you can check the IO and CPU load during startup and compare.


-Ursprüngliche Nachricht-
Von: Jerry Malcolm 
Gesendet: Mittwoch, 28. September 2022 04:54
An: users@tomcat.apache.org
Betreff: Re: Slow startup first time after reboot

Neil,

Sadly, that line doesn't appear either with or without the 
java.security.egd

option.   That appears to be a lump sum  of 4-5 minutes for the
SecureRandom seed thing.  I'm getting a total accumulation of ~5
minutes.  But it's made up of a bunch of ~15-sec web starts. See 
example
below.  Same two lines from Catalina.out from the first boot and a 
second

boot.

One other clue I've noted.  The quick boot occurs on an immediate
stop/start.  I have noticed a couple of times in Eclipse that if I 
stop TC and
leave it stopped for a while, it goes back to the long startup. It 
sounds like
something related to loading modules/jarFiles.  On an immediate 
restart the

JVM wouldn't have time to unload modules before they are needed
again.  But a new loading of some module on each web app might be 
what's

killing it (??)

   JVM Version:   11.0.16+8-LTS
   JVM Vendor:    Red Hat, Inc.

Auto-startup of TC on EC2 startup:

28-Sep-2022 00:15:55.612 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment
      of web application directory
[/var/domains/wridz.com/webapps/idmanager] has finished in 
[16,991] ms

[1 example... ~20 more like it]

28-Sep-2022 00:18:40.818 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [30]
milliseconds

Reboot of TC

28-Sep-2022 02:28:45.854 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment
     of web application directory
[/var/domains/wridz.com/webapps/idmanager] has finished in [737] 
ms [1

example... ~20 more like it]

28-Sep-2022 02:28:51.476 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [19795]
milliseconds

On 9/27/2022 8:32 PM, Neil Aggarwal wrote:

Are there perhaps
some log levels I could change that would provide more detailed
information about what step it's hung up on for loading these 
web apps?

I just tested this on a dev sever.
I removed the java.security.egd option and rebooted my

Re: tomcat cherrypick process

2022-09-29 Thread Mark Thomas

On 29/09/2022 08:08, sangeeta premani wrote:

Hi

I want to understand how commits are cherry picked from main branch to
other branches so quickly.
I observed that few commits were cherry picked from the main branch to all
3 release branches 8.5.x , 9.0.x and 10.0.x within 10 seconds.

Date - 23 august 2022
Author - Mark Thomas
Changes - Improve naming . No functional changes

*Time of commit: *


main branch -3:36:34
10.0.x branch - 3:36:45
9.0.x branch -3:36:49
8.5.x branch - 3:36:53

(i have attached the screenshot of same commit)

My question is "Are these changes go though some validations using some CI
pipelines for these release branches?"


Yes.


if yes then how can be so quick?


CI is triggered by the commit.

Mark

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



Re: OT: Question about TomcatX.exe files

2022-09-28 Thread Mark Thomas

On 28/09/2022 18:36, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, this is a silly off-topic question, but is there an underlying reason that 
the wrapper exe files for Windows Tomcat do not reflect the same file version 
as the implementation version found in the manifest of the bootstrap.jar? That 
version info matching the release version of the Tomcat release? I understand 
if these wrappers aren't recompiled each release, but if they are, why not make 
the versions reflect the Tomcat release?

This seems to throw a loop at 3rd party software discovery tools such as 
BigFix, ServiceNow, etc., as well as normalizations performed by vendors like 
Flexera.


Those files are renamed Procrun files from Commons Daemon.

The filesare never compiled as part of a Tomcat release (we use the 
binaries from Commons Daemon) but they can be renamed to anything you 
want but note the next point.


The file name reflects the default service name so you don't have to 
specify the service name every time you call the executables.


The default service name is TomcatX where X is the major version. This 
allows the service name to stay the same across minor and point release 
upgrades. Renaming the service every time you upgrade is likely to cause 
other issues - e.g. for software monitoring the service.


Other naming schemes are possible. The current scheme seems to provide a 
reasonable solution for the majority of users. That said, if the 
community disagrees, it can always be changed.


Mark




Just curious.

Thank you for your time.

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

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

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

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




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



Re: AW: Slow startup first time after reboot

2022-09-28 Thread Mark Thomas
Lots of ways. I'd try starting with the jstack tool which should be 
provided as part of the JDK you are using.


Mark


On 28/09/2022 17:16, Jerry Malcolm wrote:
Thanks, Mark, I'm not familiar with how to take a thread dump in TC. Can 
you point me to documentation on that?


Jerry


On 9/28/2022 2:56 AM, Mark Thomas wrote:
Take three thread dumps 5s apart during the slowness and then diff 
them to see what is moving and what is not.


Mark


On 28/09/2022 07:30, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,

could the underlying hardware cause the delay?
Maybe the OS has cached some data and don’t need to read it from disk 
again?


Maybe you can check the IO and CPU load during startup and compare.


-Ursprüngliche Nachricht-
Von: Jerry Malcolm 
Gesendet: Mittwoch, 28. September 2022 04:54
An: users@tomcat.apache.org
Betreff: Re: Slow startup first time after reboot

Neil,

Sadly, that line doesn't appear either with or without the 
java.security.egd

option.   That appears to be a lump sum  of 4-5 minutes for the
SecureRandom seed thing.  I'm getting a total accumulation of ~5
minutes.  But it's made up of a bunch of ~15-sec web starts. See 
example
below.  Same two lines from Catalina.out from the first boot and a 
second

boot.

One other clue I've noted.  The quick boot occurs on an immediate
stop/start.  I have noticed a couple of times in Eclipse that if I 
stop TC and
leave it stopped for a while, it goes back to the long startup. It 
sounds like
something related to loading modules/jarFiles.  On an immediate 
restart the

JVM wouldn't have time to unload modules before they are needed
again.  But a new loading of some module on each web app might be 
what's

killing it (??)

   JVM Version:   11.0.16+8-LTS
   JVM Vendor:    Red Hat, Inc.

Auto-startup of TC on EC2 startup:

28-Sep-2022 00:15:55.612 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment
      of web application directory
[/var/domains/wridz.com/webapps/idmanager] has finished in [16,991] ms
[1 example... ~20 more like it]

28-Sep-2022 00:18:40.818 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [30]
milliseconds

Reboot of TC

28-Sep-2022 02:28:45.854 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment
     of web application directory
[/var/domains/wridz.com/webapps/idmanager] has finished in [737] ms [1
example... ~20 more like it]

28-Sep-2022 02:28:51.476 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [19795]
milliseconds

On 9/27/2022 8:32 PM, Neil Aggarwal wrote:

Are there perhaps
some log levels I could change that would provide more detailed
information about what step it's hung up on for loading these web 
apps?

I just tested this on a dev sever.
I removed the java.security.egd option and rebooted my server.

Once I waited for Tomcat to finish starting up, catalina.out had 
this line:

WARNING [main]
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom
Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [222,741] milliseconds.

Check if your log has something similar.

Thank you,
    Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer
30 year loans on single family houses!

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



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



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



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



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



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



[SECURITY] CVE-2021-43980 Apache Tomcat - Information Disclosure

2022-09-28 Thread Mark Thomas

CVE-2021-43980 Apache Tomcat - Information Disclosure

Severity: High

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 10.1.0-M1 to 10.1.0-M12
Apache Tomcat 10.0.0-M1 to 10.0.18
Apache Tomcat 9.0.0-M1 to 9.0.60
Apache Tomcat 8.5.0 to 8.5.77

Description:
The simplified implementation of blocking reads and writes introduced in 
Tomcat 10 and back-ported to Tomcat 9.0.47 onwards exposed a long 
standing (but extremely hard to trigger) concurrency bug that could 
cause client connections to share an Http11Processor instance resulting 
in responses, or part responses, to be received by the wrong client.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 10.1.0-M14 or later once released
- Upgrade to Apache Tomcat 10.0.20 or later once released
- Upgrade to Apache Tomcat 9.0.62 or later once released
- Upgrade to Apache Tomcat 8.5.78 or later once released
- Note 10.1.0-M13, 10.0.19 and 9.0.61 were not released

Credit:
Thanks to Adam Thomas, Richard Hernandez and Ryan Schmitt for 
discovering the issue and working with the Tomcat security team to 
identify the root cause and appropriate fix.


History:
2022-09-28 Original advisory

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


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



Re: AW: Slow startup first time after reboot

2022-09-28 Thread Mark Thomas
Take three thread dumps 5s apart during the slowness and then diff them 
to see what is moving and what is not.


Mark


On 28/09/2022 07:30, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,

could the underlying hardware cause the delay?
Maybe the OS has cached some data and don’t need to read it from disk again?

Maybe you can check the IO and CPU load during startup and compare.


-Ursprüngliche Nachricht-
Von: Jerry Malcolm 
Gesendet: Mittwoch, 28. September 2022 04:54
An: users@tomcat.apache.org
Betreff: Re: Slow startup first time after reboot

Neil,

Sadly, that line doesn't appear either with or without the java.security.egd
option.   That appears to be a lump sum  of 4-5 minutes for the
SecureRandom seed thing.  I'm getting a total accumulation of ~5
minutes.  But it's made up of a bunch of ~15-sec web starts.  See example
below.  Same two lines from Catalina.out from the first boot and a second
boot.

One other clue I've noted.  The quick boot occurs on an immediate
stop/start.  I have noticed a couple of times in Eclipse that if I stop TC and
leave it stopped for a while, it goes back to the long startup. It sounds like
something related to loading modules/jarFiles.  On an immediate restart the
JVM wouldn't have time to unload modules before they are needed
again.  But a new loading of some module on each web app might be what's
killing it (??)

   JVM Version:   11.0.16+8-LTS
   JVM Vendor:    Red Hat, Inc.

Auto-startup of TC on EC2 startup:

28-Sep-2022 00:15:55.612 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment
      of web application directory
[/var/domains/wridz.com/webapps/idmanager] has finished in [16,991] ms
[1 example... ~20 more like it]

28-Sep-2022 00:18:40.818 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [30]
milliseconds

Reboot of TC

28-Sep-2022 02:28:45.854 INFO [main]
org.apache.catalina.startup.HostConfig.deployDirectory Deployment
     of web application directory
[/var/domains/wridz.com/webapps/idmanager] has finished in [737] ms [1
example... ~20 more like it]

28-Sep-2022 02:28:51.476 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in [19795]
milliseconds

On 9/27/2022 8:32 PM, Neil Aggarwal wrote:

Are there perhaps
some log levels I could change that would provide more detailed
information about what step it's hung up on for loading these web apps?

I just tested this on a dev sever.
I removed the java.security.egd option and rebooted my server.

Once I waited for Tomcat to finish starting up, catalina.out had this line:
WARNING [main]
org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom
Creation of SecureRandom instance for session ID generation using
[SHA1PRNG] took [222,741] milliseconds.

Check if your log has something similar.

Thank you,
Neil

--
Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com We offer
30 year loans on single family houses!

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



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



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



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



[ANN] Apache Tomcat 10.0.26 available

2022-09-27 Thread Mark Thomas

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

This release is targeted at Jakarta EE 9.

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


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

The notable changes compared to 10.0.23 include:

- Add support for authenticating WebSocket clients with an HTTP forward
  proxy when establishing a connection to a WebSocket endpoint via a
  forward proxy that requires authentication. Based on a patch provided
  by Joe Mokos.

- Various fixes for edge case bugs in EL processing

- Improve host header handling for HTTP/2 requests

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

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

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

Enjoy!

- The Apache Tomcat team

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



[ANN] Apache Tomcat 10.1.0 (stable) available

2022-09-26 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.0 (stable).

This is the first stable release of the 10.1.x branch.

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

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


The notable changes compared to 10.1.0-M17 include:

- Add support for authenticating WebSocket clients with an HTTP forward
  proxy when establishing a connection to a WebSocket endpoint via a
  forward proxy that requires authentication. Based on a patch provided
  by Joe Mokos.

- Various fixes for edge case bugs in EL processing.

- Improve host header handling for HTTP/2 requests.

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

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

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

Enjoy!

- The Apache Tomcat team

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



Re: Tomcat 8.5.8x patch upgrade failing

2022-09-23 Thread Mark Thomas

Please do not re-post the same question multiple times.

Mark


On 23/09/2022 16:20, Cannatella, Douglas wrote:


Hi All,


We are currently using Tomcat 8.5.53 and tried to upgrade patch 8.5.81 & 8.5.82 
using Ivanti Patch tool.
Our project is using OpenJDK version: 1.8.0_242, Microsoft Framework 4.0.0 
running TR/ OneSource Indirect Tax Determination
Ivanti patch tool has overlayed Tomcat service running on the D drive, on the C 
drive including war files and registry settings.  Is there any way to manual 
install >patches to keep Tomcat version 8.5.82 current on the D drive which is 
running Catalina under Windows 2019 Server.
Do I need capture logs which one's and capture Tomcat access 
log
 , or threadumps?
Next steps to download Tomcat manual installation on DEV environment?
Next step to download Apache Tomcat(r) - Apache Tomcat 8 Software 
Downloads windows-x64.zip?
https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics
Apache Tomcat 8 (8.5.82) - Tomcat 
Setup

Doug



NOTICE: This email is intended only for the individual(s) to whom it is 
addressed and may contain confidential information. If you have received this 
email by mistake, please notify the sender immediately, delete this email from 
your system and do not copy or disclose it to anyone else. Although we take 
precautions to protect against viruses, we advise you to take your own 
precautions to protect against viruses as we accept no liability for any which 
remain.



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



Re: Choosing Tomcat version for upgrade

2022-09-22 Thread Mark Thomas

On 22/09/2022 12:21, Gowtham Varma Buddharaju wrote:

Hi All,

We are currently using Tomcat 8 and want to upgrade as it has reached EOL.
Our project uses servlet spec 3.1. I understand upgrading to 8.5 from 8
will be very easy, but till when will 8.5 be supported? If we upgrade to 9
should we upgrade servlet spec in our application pom.xml from 3.1 to 4.0?
Also till when is Tomcat 9 supported?


The official position is:
- No end of life decisions have yet been made for Tomcat 8.5.x onwards.
- Any such decisions will provide at least 12 months notice.

Based on past experience, I'd *guess* that:
- Tomcat 8.5.x will no EOL no earlier than 31 March 2024
- Tomcat 9.0.x will be EOL no earlier than 31 March 2027

There is no need up update the specification version in your web 
application to run on a newer version of Tomcat


Mark

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



Re: Question about windows servers support platform for Tomcat 7 and Tomcat 9

2022-09-21 Thread Mark Thomas

On 21/09/2022 09:16, Terry ST SY/OGCIO wrote:

Dear Mark,

Many thanks for your reply.
As there is some limitation/dependence on upgrade Tomcat 7, may I know Tomcat 7 
the windows platform support status before Tomcat 7 end of support.


Tomcat 7 was supported on any Windows platform supported by Microsoft.

Mark



Regards,
Terry


-Original Message-
From: Mark Thomas 
Sent: Wednesday, September 21, 2022 4:10 PM
To: users@tomcat.apache.org
Subject: Re: Question about windows servers support platform for Tomcat 7 and 
Tomcat 9

On 21/09/2022 08:03, Terry ST SY/OGCIO wrote:

Dear Support,

We are using Tomcat 7 with Windows Server 2012 R2 at our servers and planned to 
upgrade tomcat and windows platform.

Can you update us the windows support platform for Tomcat 7 and Tomcat 9 for 
our ease planning.


Apache Tomcat 7 reached end of life 18 months ago and is no longer
supported:

https://tomcat.apache.org/tomcat-70-eol.html

Apache Tomcat 9.0.x is currently supported and, based on support periods for 
previous versions, I'd expect that support to last for a further 4-5 years. The 
end of life date, when decided, will be announced with at least 12 months 
notice.

Apache Tomcat 9 is a special case since it is the last version that implements 
Java EE (Tomcat 10 onwards implement Jakarta EE). The Tomcat community expects 
to provide support for Tomcat 9 for as long as there is a demand for a version 
of Tomcat that supports Java EE.

The exact detail of how extended Tomcat 9 support will work is TBD but it will 
be something like once Tomcat 9.0.x reaches end of life, Tomcat 9.10.x will be 
released which will be Tomcat 10 but with Java EE support. Once Tomcat 10 
reaches end of life, so will 9.10.x and 9.11.x will be released which will be 
Tomcat 11 but with Java EE support and so on.

Apache Tomcat is supported on any Windows platform currently supported by 
Microsoft.

Mark

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


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



Re: Question about windows servers support platform for Tomcat 7 and Tomcat 9

2022-09-21 Thread Mark Thomas

On 21/09/2022 08:03, Terry ST SY/OGCIO wrote:

Dear Support,

We are using Tomcat 7 with Windows Server 2012 R2 at our servers and planned to 
upgrade tomcat and windows platform.

Can you update us the windows support platform for Tomcat 7 and Tomcat 9 for 
our ease planning.


Apache Tomcat 7 reached end of life 18 months ago and is no longer 
supported:


https://tomcat.apache.org/tomcat-70-eol.html

Apache Tomcat 9.0.x is currently supported and, based on support periods 
for previous versions, I'd expect that support to last for a further 4-5 
years. The end of life date, when decided, will be announced with at 
least 12 months notice.


Apache Tomcat 9 is a special case since it is the last version that 
implements Java EE (Tomcat 10 onwards implement Jakarta EE). The Tomcat 
community expects to provide support for Tomcat 9 for as long as there 
is a demand for a version of Tomcat that supports Java EE.


The exact detail of how extended Tomcat 9 support will work is TBD but 
it will be something like once Tomcat 9.0.x reaches end of life, Tomcat 
9.10.x will be released which will be Tomcat 10 but with Java EE 
support. Once Tomcat 10 reaches end of life, so will 9.10.x and 9.11.x 
will be released which will be Tomcat 11 but with Java EE support and so on.


Apache Tomcat is supported on any Windows platform currently supported 
by Microsoft.


Mark

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



Re: AW: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox

2022-09-21 Thread Mark Thomas

On 21/09/2022 06:48, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hallo Mark,

thank you for the explanation.
Could you guide me in this case?
Shall I set all logging options in tomcat to trace (logging.properties)?


Thomas,

The level of logging in your most recent off-list trace was perfect. The 
issue was that the logging did not show the problem you described.


The issue you described is that the client resets a single stream and 
Tomcat then incorrectly closes the entire connection. That in turns 
triggers stack traces in the logs as the application attempts to write 
to the other streams in the connection as those streams are now closed.


I could not find any evidence of that in the logging you provided. Every 
stack trace associated with a write to a closed stream was preceded by 
the client sending a reset frame for that stream.


You need to:

- recreate the case of Tomcat closing an entire connection in response
  to the client resetting a single stream
- capture HTTP/2 debug logs when this occurs
- provide those logs

Mark




Thanks! Thomas


-Ursprüngliche Nachricht-
Von: Mark Thomas 
Gesendet: Dienstag, 20. September 2022 22:28
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
sometimes closes connection with Firefox

On 20/09/2022 20:22, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,


-Ursprüngliche Nachricht-
Von: Mark Thomas 
Gesendet: Dienstag, 20. September 2022 20:13
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
sometimes closes connection with Firefox

On 20/09/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,


I will send you the log and access-log to your email address.

I am not sure whether it contradicts the observation.


For example:

- Browser opens a TCP-connection and requests the HTML page.

- Tomcat sends single packages with HTML via http2-stream no 1.

- Browser requests CSS via http2-stream no 2.

- Tomcat serves HTML via stream 1 and css via stream 2.

- Browser closes stream 2 which triggers tomcat to close the whole
TCP

connection including stream 1.


- Thus the html stream is also cancelled, leading to a partly
visible html

page.

Thomas,

I can find no evidence of the sequence above in the logs you provided.
In all the cases I could find, the client first reset the stream
sending
0x08 (cancel) as the reason.

If you can provide a connection and stream id that exhibits the
behaviour you are describing, I'll be happy to look at it.

Mark


I can record a network trace with wireshark if this helps.
The last time I saw that the browser aborts one stream as you described.
It shouldn’t close the whole TCP connection, just the stream.
I try to get a wireshark dump on weekend.


Thomas,

A wireshark trace is unlikely to help. I need the Tomcat debug logs to see
what is happening internally.

You need to provide the debug log trace for an instance where Tomcat
closes the entire connection after the client resets a single stream.

In all the examples in the previous log, every time there was a stack trace for
a stream, it was preceeded by the client resetting that stream
- and hence was normal behaviour.

Mark


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



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



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



Re: AW: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox

2022-09-20 Thread Mark Thomas

On 20/09/2022 20:22, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,


-Ursprüngliche Nachricht-
Von: Mark Thomas 
Gesendet: Dienstag, 20. September 2022 20:13
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression
sometimes closes connection with Firefox

On 20/09/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,


I will send you the log and access-log to your email address.

I am not sure whether it contradicts the observation.


For example:

- Browser opens a TCP-connection and requests the HTML page.

- Tomcat sends single packages with HTML via http2-stream no 1.

- Browser requests CSS via http2-stream no 2.

- Tomcat serves HTML via stream 1 and css via stream 2.

- Browser closes stream 2 which triggers tomcat to close the whole TCP

connection including stream 1.


- Thus the html stream is also cancelled, leading to a partly visible html

page.

Thomas,

I can find no evidence of the sequence above in the logs you provided.
In all the cases I could find, the client first reset the stream sending
0x08 (cancel) as the reason.

If you can provide a connection and stream id that exhibits the behaviour you
are describing, I'll be happy to look at it.

Mark


I can record a network trace with wireshark if this helps.
The last time I saw that the browser aborts one stream as you described.
It shouldn’t close the whole TCP connection, just the stream.
I try to get a wireshark dump on weekend.


Thomas,

A wireshark trace is unlikely to help. I need the Tomcat debug logs to 
see what is happening internally.


You need to provide the debug log trace for an instance where Tomcat 
closes the entire connection after the client resets a single stream.


In all the examples in the previous log, every time there was a stack 
trace for a stream, it was preceeded by the client resetting that stream 
- and hence was normal behaviour.


Mark


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



Re: AW: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox

2022-09-20 Thread Mark Thomas

On 20/09/2022 17:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,


I will send you the log and access-log to your email address.

I am not sure whether it contradicts the observation.


For example:

- Browser opens a TCP-connection and requests the HTML page.

- Tomcat sends single packages with HTML via http2-stream no 1.

- Browser requests CSS via http2-stream no 2.

- Tomcat serves HTML via stream 1 and css via stream 2.

- Browser closes stream 2 which triggers tomcat to close the whole TCP 
connection including stream 1.

- Thus the html stream is also cancelled, leading to a partly visible html page.


Thomas,

I can find no evidence of the sequence above in the logs you provided. 
In all the cases I could find, the client first reset the stream sending 
0x08 (cancel) as the reason.


If you can provide a connection and stream id that exhibits the 
behaviour you are describing, I'll be happy to look at it.


Mark





I hope the logs will provide more information.


Thanks! Thomas



Von: Mark Thomas 
Gesendet: Dienstag, 20. September 2022 09:04
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes 
connection with Firefox

On 19/09/2022 19:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,

thanks for the update.

The commit looked promising. I tried with Tomcat 10.1 M17 but unfortunately it 
didn't help.

The partly loaded website is still occuring.


Setting http2 logging to fine, I can see the following stack:


That looks like the client reset the stream but that doesn't match what
you are observing which sounds like Tomcat is truncating the response.


19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9] 
org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW] 
reported while processing request
org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream 
is not writable


That this is happening with connection 1 is good. It means it should be
easy to reproduce. Please can you:
- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs

I want to trace what is happening on the HTTP/2 connection leading up to
the truncation occurring.

Thanks,

Mark



at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
at 
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
at 
org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
at 
org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
at org.apache.coyote.Response.action(Response.java:210)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream 
[23], This stream is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
... 20 more



Looks like the Exception bubbles up from the last line of tthis method:

  void doStreamCancel(String msg, Http2Error error) throws 
CloseNowException {
  StreamException se = new StreamException(msg, error, getIdAsInt());
  // Prevent the application making further writes
  streamOutputBuffer.closed = true;
  // Prevent Tomcat's error handling trying to write
  coyoteResponse.setError();
  coyoteResponse.setErrorReported();
  // Trigger a reset once control returns to Tomcat
  streamOutputBuffer.reset = se;
  throw new CloseNowException(msg, se);
  }

The CloseNowException() bubbles up without being caught maybe (?)
Stream.write(...) is not contained here.

Greetings, Thoas


Von: Mark Thomas 
Gesendet: Montag, 19. September 2022 19:22
An: users

[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.4

2022-09-20 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.4

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.3 include:

- Improve the fix converting web applications that include JARs that
  store one or more entries in uncompressed form

- Add a new conversion profile that converts from Jakarta EE 9 to Java
  EE 8

Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

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

Enjoy!

- The Apache Tomcat team


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



Re: AW: AW: AW: Tomcat 10 with Http2 and compression sometimes closes connection with Firefox

2022-09-20 Thread Mark Thomas

On 19/09/2022 19:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,

thanks for the update.

The commit looked promising. I tried with Tomcat 10.1 M17 but unfortunately it 
didn't help.

The partly loaded website is still occuring.


Setting http2 logging to fine, I can see the following stack:


That looks like the client reset the stream but that doesn't match what 
you are observing which sounds like Tomcat is truncating the response.



19-Sep-2022 20:07:16.651 FEIN [https-openssl-nio-443-exec-9] 
org.apache.coyote.AbstractProcessor.setErrorState Error state [CLOSE_NOW] 
reported while processing request
org.apache.coyote.CloseNowException: Connection [1], Stream [23], This stream 
is not writable


That this is happening with connection 1 is good. It means it should be 
easy to reproduce. Please can you:

- enable debug logging for HTTP/2
- restart Tomcat
- trigger this problem
- provide the full debug logs

I want to trace what is happening on the HTTP/2 connection leading up to 
the truncation occurring.


Thanks,

Mark



at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:258)
at 
org.apache.coyote.http2.Http2UpgradeHandler.reserveWindowSize(Http2UpgradeHandler.java:919)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:945)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.flush(Stream.java:891)
at org.apache.coyote.http2.Stream$StreamOutputBuffer.end(Stream.java:990)
at 
org.apache.coyote.http11.filters.GzipOutputFilter.end(GzipOutputFilter.java:128)
at org.apache.coyote.http2.Http2OutputBuffer.end(Http2OutputBuffer.java:71)
at 
org.apache.coyote.http2.StreamProcessor.finishResponse(StreamProcessor.java:230)
at org.apache.coyote.AbstractProcessor.action(AbstractProcessor.java:391)
at org.apache.coyote.Response.action(Response.java:210)
at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:258)
at org.apache.catalina.connector.Response.finishResponse(Response.java:418)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:388)
at org.apache.coyote.http2.StreamProcessor.service(StreamProcessor.java:426)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.http2.StreamProcessor.process(StreamProcessor.java:87)
at org.apache.coyote.http2.StreamRunnable.run(StreamRunnable.java:35)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.coyote.http2.StreamException: Connection [1], Stream 
[23], This stream is not writable
at org.apache.coyote.http2.Stream.doStreamCancel(Stream.java:250)
... 20 more



Looks like the Exception bubbles up from the last line of tthis method:

 void doStreamCancel(String msg, Http2Error error) throws CloseNowException 
{
 StreamException se = new StreamException(msg, error, getIdAsInt());
 // Prevent the application making further writes
 streamOutputBuffer.closed = true;
 // Prevent Tomcat's error handling trying to write
 coyoteResponse.setError();
 coyoteResponse.setErrorReported();
 // Trigger a reset once control returns to Tomcat
 streamOutputBuffer.reset = se;
 throw new CloseNowException(msg, se);
 }

The CloseNowException() bubbles up without being caught maybe (?)
Stream.write(...) is not contained here.

Greetings, Thoas


Von: Mark Thomas 
Gesendet: Montag, 19. September 2022 19:22
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Tomcat 10 with Http2 and compression sometimes closes 
connection with Firefox

Thomas,

Please update to the latest 10.1.x release and re-test. There is what
looks like a fix for this issue in 10.1.0-M12:

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

Mark


On 01/08/2022 21:46, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,

I would create a ticket and sum up all the collected information about this 
issue, if there are no further suggestions.

Closing a single stream in http2 causes an internal exception in 
StreamProcessor which bubbles up in different ways, depending whether 
http-compression is active or not.
In the first case it leads to closing the complete TCP connection.

Thanks! Thomas



-Ursprüngliche Nachricht-
Von: Thomas Hoffmann (Speed4Trade GmbH)

Gesendet: Donnerstag, 28. Juli 2022 22:25
An: Tomcat Users List 
Betreff: AW: AW: Tomcat 10 with Http2 and compression sometimes closes
connection with Firefox

Hello Mark,

I got a stack trace which also shows the involvement of the gzip filter. I set
the loglevel for the http2-StreamProcessor to get the details.
The stack trace was written when the problem with FF occurred.
FF closed one single

Re: Tomcat 9.0.65 suspected memory leak

2022-09-19 Thread Mark Thomas

On 15/09/2022 14:11, Chen Levy wrote:

Hello Experts

We’ve recently upgraded some of our production servers to Tomcat 9.0.65; 
every upgraded server crashed with java.lang.OutOfMemoryError within an 
hour or so under load.


The exact same setup (same application, Linux kernel, Java version etc.) 
with Tomcat 9.0.63 does not exhibit this issue.


A heap-dump through MAT gave the following leak suspect (leak report 
attached):


“

14,364 instances of 
"org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper", loaded by 
"java.net.URLClassLoader @ 0x6be257090" occupy 4,489,221,944 (91.95%) bytes.


These instances are referenced from one instance of 
"java.util.concurrent.ConcurrentHashMap$Node[]", loaded by "class loader>", which occupies 590,736 (0.01%) bytes.


Keywords

     org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper

     java.net.URLClassLoader @ 0x6be257090

     java.util.concurrent.ConcurrentHashMap$Node[]

“

Please let me know if I should provide additional information


That looks like 14k current connections which isn't unreasonable for a 
Tomcat instance under load.


There are connector related changes between 9.0.63 and 9.0.65 but 
nothing that is obviously related to the issue you are seeing.


At this point there isn't enough information to differentiate between:
- a regression introduced in Tomcat between 9.0.63 and 9.0.65
- a change in Tomcat between 9.0.63 and 9.0.65 that exposed a bug in the
  deployed web application
- a change in Tomcat between 9.0.63 and 9.0.65 that triggered an
  increase memory usage sufficient to trigger an OOME in your
  environment

What we would need to investigate this further is a test case that 
demonstrates a leak. It doesn't have to trigger an OOME - it just has to 
demonstrate the JVM retaining references to objects you'd expect to have 
been eligible for GC. If you can reduce it to a single request even better.


Mark

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



Re: tomcats starting with 200 threads

2022-09-19 Thread Mark Thomas
If the machine / VM / container you are running Tomcat on can't handle 
200 threads you should be using a smaller value for maxThreads.


Mark


On 19/09/2022 15:46, Jonathan Yom-Tov wrote:

hi,

Sometimes one of our production Tomcats will start with the maximum (200)
number of threads in the https pool. That is, it doesn't start with some
minimum and works its way up to the maximum, it immediately starts with the
maximum. There's no reason for it since most of the threads stay idle
through the lifetime of the Tomcat. The issue is that this takes up memory
and eventually something pushes the Tomcat over the edge and it dies with
an out of memory error. Any ideas on how to debug or solve this?

The Tomcat version is 9.0.64.0, running on Amazon Linux 2 (amd64) and Java
Corretto 1.8.0_312-b07.

Thanks,
Jon.



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



Re: Tomcat 9 - Missing auth-constraint configuration appears to allow access to protected content

2022-09-18 Thread Mark Thomas

On 17/09/2022 14:46, Kerry wrote:




I deployed a stand-alone instance of Tomcat with the following web.xml:

http://xmlns.jcp.org/xml/ns/javaee;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd;
   version="4.0"
   metadata-complete="true">

   Security Test Deployment
   
  Testing of Security constraints.
   
     
     privileged
     >
     
     
     protected pages
     /protected/*
     
     


I then placed two jsp files in the root folder for the application:

1. index.jsp  - in the root folder for the application

2. protected.jsp in a sub-folder 'protected' to match the above url-pattern

I found that with this configuration I was able to access 
/protected/protected.jsp without any authorisation.


This behaviour is correct. As per section 13.8 of the Servlet specification:

"If no authorization constraint applies to a request, the container must 
accept the request without requiring user authentication."


Note: An "authorization constraint" is the "" element 
that may be nested under a "" element.


> However I found that if I placed an empty 'auth-constraint' element in 
the web.xml then I could NOT access /protected/protected.jsp without 
authorisation. e.g include the following in web.xml:






This behaviour is correct. As per section 13.8 of the Servlet specification:

"An authorization constraint that names no roles indicates that
access to the constrained requests must not be permitted under any 
circumstances."


As you have found "No authorization constraint" != "Authorization 
constraint without any roles".


In some respects this does comply with the servlet spec. because no 
roles were given however I would have expected if the 'auth-constraint' 
were missing it would be the same as it existing but with no roles 
specified.


Your expectation is not correct. It is an understandable expectation, 
but it is not correct.


Further, I also found that attempting to limit the type of http method 
used did not appear to work. e.g. having:


Security Test Deployment

  Testing of Security constraints.


     privileged
>

     
     protected pages
     /protected/*
     
     
     privileged
     
     PUT


I anticipated an unauthorised  GET on the /protected/* url to fail but 
completes successfully.


This is also correct. If you specify HTTP methods as part of a 
constraint then the constraint applies ONLY to those methods.


See section 13.8.4 for more details of constraints and uncovered HTTP 
methods.


I have tried the above steps on an instance of Jetty and it exhibits the 
same behaviour as Tomcat.  I have little direct experience of working 
with either Tomcat or Jetty and with Spring Boot and the Keycloak Spring 
Boot starter I am one step removed from the Tomcat configuration.


My concern here is that it appears quite easy to misconfigure Tomcat via 
the Keycloak application.properties and not be aware of unsecured end 
points. If this is an issue then it appears to lie within Tomcat as I 
can reproduce my original issue seen with a Spring Boot application in a 
stand-alone instance of Tomcat and a simple hand-craft application 
deployed to it.


There is no Tomcat issue here. Tomcat is behaving as required by the 
Servlet specification.


I strongly recommend reading the relevant sections of the Servlet 
specification.



Is what I am seeing expected behaviour?


Yes.

Mark

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



[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.3

2022-09-12 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.3

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.1 include:

- Update checksums for modified files to avoid issues when trying to use
  migrated JAR files
- Handle migration of manifest files when part of an exploded JAR


Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

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

Enjoy!

- The Apache Tomcat team


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



Re: [External] Re: Customizing CorsFilter

2022-09-07 Thread Mark Thomas

On 07/09/2022 12:22, Amit Pande wrote:

Thank you, Mark! Will do some more research on this and see if I can leverage 
this.

However, are we still okay refactoring the CorsFilter for extension?


Yes, I am sure the committers will consider any such proposal.

Mark




Thanks,
Amit



-Original Message-
From: Mark Thomas 
Sent: Wednesday, September 7, 2022 6:18 AM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Customizing CorsFilter

On 07/09/2022 11:42, Amit Pande wrote:

Could you please share more details on "web.xml" changes and dynamic reload of 
applications? Some documentation link or something would be helpful. I couldn't find 
anything online.


The documentation is rather sparse.

See conf/web.xml and look at the nested WatchedResource elements.

If a reload of a running application is triggered the following happens:
- new requests are allowed but made to wait
- existing requests are allowed to complete
- the web application is stopped
- the web application is started (picking up any new configuration)
- any waiting new requests are allowed to proceed

By default, any open sessions will be lost. If using the StandardManager you 
can configure it to persist session across web application (and
Tomcat) restarts.


Also, wanted to check with the community - how they handle such a requirement 
where the CORS allowed origins can change over time -presumably infrequently 
but still.
Manual edit of web.xml and leverage the reload of apps? Or server restart? What 
is the best/safe way to edit the main web.xml?


Personally, I'd just edit web.xml but I only manage my own very lightly used 
web applications. Provided you don't have long running requests I'd recommend 
that approach.

For editing web.xml, if you want to be sure use a schema aware XML editor. That 
should a) ensure it is syntactically correct and b) provide auto-completion 
options. I normally use an IDE.

Mark




Thanks,
Amit

-Original Message-----
From: Mark Thomas 
Sent: Wednesday, September 7, 2022 1:37 AM
To: users@tomcat.apache.org
Subject: [External] Re: Customizing CorsFilter



On 07/09/2022 07:31, Mark Thomas wrote:

On 06/09/2022 18:42, Amit Pande wrote:

Hello all,

I am currently using the Tomcat 9.0.65 (9.x) and looking at the
possibility of extending the
CorsFilter<https://nam12.safelinks.protection.outlook.com/?url=https
%
3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23
C
ORS_Filterdata=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66
e
49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63
7
981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
V
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UVYm
M wnGj19cJCuA0Nlc%2Few5SMMGF2nXyJiFasO11hc%3Dreserved=0>,
specially the configuration part.

I am looking at the ability to initialize the parameters of Tomcat's
CorsFilter from a source other than "web.xml" (one under
TOMCAT_INSTALL_DIR/conf - so that settings apply for all
applications inside this web server). E.g., the configuration could
a key-value data store (or a simple property file).

Hand-editing the "web.xml" could be calling for trouble if not done
carefully. And AFAICT, there isn't any tooling/interface to allow
easily and reliably editing the "web.xml".

Also, ability to poll the external configuration source allows
dynamically reload the CorsFilter configuration without requiring
the Tomcat restart. In certain product deployments, web server is
just a part and having to restart for some configuration changes to
take effect isn't desired, though isn't not a must-have.


I was looking for something like:

public class CustomCorsFilter extends CorsFilter {

@Override
public void init() {

// load configuration from some other persistence store //
initialize fields from super class (which are then used in the
actual CORS
validation) }

     @Override
   public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain)
   throws IOException, ServletException {
   super.doFilter(request, response, chain);
   }

}

// Additionally, the init can be called periodically which could
re-initialize the fields from CorsFilter class.

However, currently, the configuration fields are private and there
are no setters.

Before I explore the option of looking for adding interface to "edit"
the web.xml, wanted to check if it's possible to update the
CorsFilter and make some methods protected (e.g.
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
t
hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fca
t
alina%2Ffilters%2FCorsFilter.java%23L712data=05%7C01%7CAmit.Pan
d
e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c5
5
b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3
d
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
7
C3000%7C%7C%7Csdata=SaFrY7

Re: [External] Re: Customizing CorsFilter

2022-09-07 Thread Mark Thomas

On 07/09/2022 11:42, Amit Pande wrote:

Could you please share more details on "web.xml" changes and dynamic reload of 
applications? Some documentation link or something would be helpful. I couldn't find 
anything online.


The documentation is rather sparse.

See conf/web.xml and look at the nested WatchedResource elements.

If a reload of a running application is triggered the following happens:
- new requests are allowed but made to wait
- existing requests are allowed to complete
- the web application is stopped
- the web application is started (picking up any new configuration)
- any waiting new requests are allowed to proceed

By default, any open sessions will be lost. If using the StandardManager 
you can configure it to persist session across web application (and 
Tomcat) restarts.



Also, wanted to check with the community - how they handle such a requirement 
where the CORS allowed origins can change over time -presumably infrequently 
but still.
Manual edit of web.xml and leverage the reload of apps? Or server restart? What 
is the best/safe way to edit the main web.xml?


Personally, I'd just edit web.xml but I only manage my own very lightly 
used web applications. Provided you don't have long running requests I'd 
recommend that approach.


For editing web.xml, if you want to be sure use a schema aware XML 
editor. That should a) ensure it is syntactically correct and b) provide 
auto-completion options. I normally use an IDE.


Mark




Thanks,
Amit

-Original Message-----
From: Mark Thomas 
Sent: Wednesday, September 7, 2022 1:37 AM
To: users@tomcat.apache.org
Subject: [External] Re: Customizing CorsFilter



On 07/09/2022 07:31, Mark Thomas wrote:

On 06/09/2022 18:42, Amit Pande wrote:

Hello all,

I am currently using the Tomcat 9.0.65 (9.x) and looking at the
possibility of extending the
CorsFilter<https://nam12.safelinks.protection.outlook.com/?url=https%
3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23C
ORS_Filterdata=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66e
49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637
981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=UVYmM
wnGj19cJCuA0Nlc%2Few5SMMGF2nXyJiFasO11hc%3Dreserved=0>,
specially the configuration part.

I am looking at the ability to initialize the parameters of Tomcat's
CorsFilter from a source other than "web.xml" (one under
TOMCAT_INSTALL_DIR/conf - so that settings apply for all applications
inside this web server). E.g., the configuration could a key-value
data store (or a simple property file).

Hand-editing the "web.xml" could be calling for trouble if not done
carefully. And AFAICT, there isn't any tooling/interface to allow
easily and reliably editing the "web.xml".

Also, ability to poll the external configuration source allows
dynamically reload the CorsFilter configuration without requiring the
Tomcat restart. In certain product deployments, web server is just a
part and having to restart for some configuration changes to take
effect isn't desired, though isn't not a must-have.


I was looking for something like:

public class CustomCorsFilter extends CorsFilter {

@Override
public void init() {

// load configuration from some other persistence store // initialize
fields from super class (which are then used in the actual CORS
validation) }

    @Override
  public void doFilter(ServletRequest request, ServletResponse
response, FilterChain chain)
  throws IOException, ServletException {
  super.doFilter(request, response, chain);
  }

}

// Additionally, the init can be called periodically which could
re-initialize the fields from CorsFilter class.

However, currently, the configuration fields are private and there
are no setters.

Before I explore the option of looking for adding interface to "edit"
the web.xml, wanted to check if it's possible to update the
CorsFilter and make some methods protected (e.g.
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fcat
alina%2Ffilters%2FCorsFilter.java%23L712data=05%7C01%7CAmit.Pand
e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c55
b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3d
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
C3000%7C%7C%7Csdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ4s
WgY%3Dreserved=0)
for extension.


Refactoring the CorsFilter to make it extensible is certainly an option.
Some things to keep in mind:

- Increasing the visibility of methods is unlikely to be controversial

- Getters and setters are preferred to non-private fields

- Any changes need to be backwards compatible

- Supporting dynamic reconfiguration means ensuring that any such
configuration changes are made in a thread-safe manner

Re: Customizing CorsFilter

2022-09-07 Thread Mark Thomas




On 07/09/2022 07:31, Mark Thomas wrote:

On 06/09/2022 18:42, Amit Pande wrote:

Hello all,

I am currently using the Tomcat 9.0.65 (9.x) and looking at the 
possibility of extending the 
CorsFilter<https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter>, 
specially the configuration part.


I am looking at the ability to initialize the parameters of Tomcat's 
CorsFilter from a source other than "web.xml" (one under 
TOMCAT_INSTALL_DIR/conf - so that settings apply for all applications 
inside this web server). E.g., the configuration could a key-value 
data store (or a simple property file).


Hand-editing the "web.xml" could be calling for trouble if not done 
carefully. And AFAICT, there isn't any tooling/interface to allow 
easily and reliably editing the "web.xml".


Also, ability to poll the external configuration source allows 
dynamically reload the CorsFilter configuration without requiring the 
Tomcat restart. In certain product deployments, web server is just a 
part and having to restart for some configuration changes to take 
effect isn't desired, though isn't not a must-have.



I was looking for something like:

public class CustomCorsFilter extends CorsFilter {

@Override
public void init() {

// load configuration from some other persistence store
// initialize fields from super class (which are then used in the 
actual CORS validation)

}

   @Override
 public void doFilter(ServletRequest request, ServletResponse 
response, FilterChain chain)

 throws IOException, ServletException {
 super.doFilter(request, response, chain);
 }

}

// Additionally, the init can be called periodically which could 
re-initialize the fields from CorsFilter class.


However, currently, the configuration fields are private and there are 
no setters.


Before I explore the option of looking for adding interface to "edit" 
the web.xml, wanted to check if it's possible to update the CorsFilter 
and make some methods protected (e.g. 
https://github.com/apache/tomcat/blob/9.0.65/java/org/apache/catalina/filters/CorsFilter.java#L712) 
for extension.


Refactoring the CorsFilter to make it extensible is certainly an option. 
Some things to keep in mind:


- Increasing the visibility of methods is unlikely to be controversial

- Getters and setters are preferred to non-private fields

- Any changes need to be backwards compatible

- Supporting dynamic reconfiguration means ensuring that any such 
configuration changes are made in a thread-safe manner. Note that the 
configuration could change in the middle of a request being processed by 
the filter.


That last point is the potentially tricky one. My concern would be the 
performance impacts of any measures taken to ensure thread safety.


Something that occurred to me just after I pressed send was that Tomcat 
has a built-in, general solution to the reconfiguration problem. In a 
default configuration, changes to web.xml will trigger a graceful reload 
of the web application.


Mark

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



Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

2022-09-07 Thread Mark Thomas

On 07/09/2022 04:22, Terence M. Bandoian wrote:

It looks like there's something going on with the CRLF sequence that 
should separate the header section from the body in digest attachments. 
However, it's difficult to tell where it's happening.


 From RFC 5322:

    A message consists of header fields (collectively called "the header
    section of the message") followed, optionally, by a body.  The header
    section is a sequence of lines of characters with special syntax as
    defined in this specification.  The body is simply a sequence of
    characters that follows the header section and is separated from the
    header section by an empty line (i.e., a line with nothing preceding
    the CRLF).

In Thunderbird, in every attachment that is displayed as blank or is 
missing a leading portion of the message, there is no empty line between 
the header section and the body in the message source.


In gmail, those attachments are displayed, mostly, but when I download 
the source, there is no empty line separating the header section from 
the body. I say mostly because, in some cases, gmail does not display a 
leading portion of the message, but starts after the first blank line.


This suggests that the digest is not including empty lines between the 
header section and body of attachments. I found a couple of digests from 
2020 and, in all attachments, an empty line was included between the 
header section and body.


Has the digest code changed recently?


Thanks for looking into this.

ezmlm (the software that runs the mailing lists) was updated around the 
time you first reported these problems.


Please raise the issue of the missing line with the ASF infrastructure 
team as they manage ezmlm for all ASF projects.


Thanks again,

Mark

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



Re: Customizing CorsFilter

2022-09-07 Thread Mark Thomas

On 06/09/2022 18:42, Amit Pande wrote:

Hello all,

I am currently using the Tomcat 9.0.65 (9.x) and looking at the possibility of 
extending the 
CorsFilter,
 specially the configuration part.

I am looking at the ability to initialize the parameters of Tomcat's CorsFilter from a 
source other than "web.xml" (one under TOMCAT_INSTALL_DIR/conf - so that 
settings apply for all applications inside this web server). E.g., the configuration 
could a key-value data store (or a simple property file).

Hand-editing the "web.xml" could be calling for trouble if not done carefully. And 
AFAICT, there isn't any tooling/interface to allow easily and reliably editing the 
"web.xml".

Also, ability to poll the external configuration source allows dynamically 
reload the CorsFilter configuration without requiring the Tomcat restart. In 
certain product deployments, web server is just a part and having to restart 
for some configuration changes to take effect isn't desired, though isn't not a 
must-have.


I was looking for something like:

public class CustomCorsFilter extends CorsFilter {

@Override
public void init() {

// load configuration from some other persistence store
// initialize fields from super class (which are then used in the actual CORS 
validation)
}

   @Override
 public void doFilter(ServletRequest request, ServletResponse response, 
FilterChain chain)
 throws IOException, ServletException {
 super.doFilter(request, response, chain);
 }

}

// Additionally, the init can be called periodically which could re-initialize 
the fields from CorsFilter class.

However, currently, the configuration fields are private and there are no 
setters.

Before I explore the option of looking for adding interface to "edit" the 
web.xml, wanted to check if it's possible to update the CorsFilter and make some methods 
protected (e.g. 
https://github.com/apache/tomcat/blob/9.0.65/java/org/apache/catalina/filters/CorsFilter.java#L712)
 for extension.


Refactoring the CorsFilter to make it extensible is certainly an option. 
Some things to keep in mind:


- Increasing the visibility of methods is unlikely to be controversial

- Getters and setters are preferred to non-private fields

- Any changes need to be backwards compatible

- Supporting dynamic reconfiguration means ensuring that any such 
configuration changes are made in a thread-safe manner. Note that the 
configuration could change in the middle of a request being processed by 
the filter.


That last point is the potentially tricky one. My concern would be the 
performance impacts of any measures taken to ensure thread safety.


Mark

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



[ANN] New committer: Han Li

2022-09-06 Thread Mark Thomas

On behalf of the Tomcat committers I am delighted to announce that
Han Li (lihan) has been voted in as a new Tomcat committer.

Please join me in congratulating Han.

Kind regards,

Mark

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



Re: Issue with SSL connector in tomcat 10.0.23

2022-09-05 Thread Mark Thomas

On 05/09/2022 14:37, saicharan.bu...@wellsfargo.com.INVALID wrote:

Thanks Thomas,

Now that we don't see the error but seeing one warning message for below:

WARNING [main] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match 
[Server/Service/Connector] failed to set property [clientAuth] to [false]

I don't find any equivalent attribute for clientAuth in the documentation.


It is certificateVerification on the Connector.

Mark




PFB snippet of our server.xml file


  

Thanks,
Saicharan Burle

-Original Message-
From: Thomas Hoffmann (Speed4Trade GmbH) 

Sent: Monday, September 5, 2022 5:56 PM
To: Tomcat Users List 
Subject: AW: Issue with SSL connector in tomcat 10.0.23

Hello,


-Ursprüngliche Nachricht-
Von: saicharan.bu...@wellsfargo.com.INVALID

Gesendet: Montag, 5. September 2022 14:11
An: users@tomcat.apache.org
Betreff: Issue with SSL connector in tomcat 10.0.23

Hi Team,

We are facing issues with the Tomcat 10.0.23 version while starting as
it's not accepting few of the SSL parameters. PFB error message

05-Sep-2022 04:51:01.144 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed
to initialize component [Connector[HTTP/1.1-8004]]
 org.apache.catalina.LifecycleException: Protocol
handler initialization failed
 at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1055)
 at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
 at
org.apache.catalina.core.StandardService.initInternal(StandardService.
java:556
)
 at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
 at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1045)
 at
org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)
 at
org.apache.catalina.startup.Catalina.load(Catalina.java:747)
 at
org.apache.catalina.startup.Catalina.load(Catalina.java:769)
 at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
62)
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orI
mpl.java:43)
 at 
java.lang.reflect.Method.invoke(Method.java:498)
 at
org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:305)
 at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)
 Caused by: java.lang.IllegalArgumentException: No
SSLHostConfig element was found with the hostName [_default_] to match
the defaultSSLHostConfigName for the connector [https-jsse-nio-8004]
 at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstract
JsseEndpoi
nt.java:76)
 at
org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:206)
 at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEn
dpoin
t.java:1192)
 at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1205)
 at
org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:580)
 at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
tocol.j
ava:82)
 at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1052)
 ... 13 more

Also, We are seeing some warning messages below:

05-Sep-2022 04:51:00.733 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
[Server/Service/Connector] failed to set property [sslProtocol] to
[TLS]
05-Sep-2022 04:51:00.733 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
[Server/Service/Connector] failed to set property
[sslEnabledProtocols] to [TLSv1.2]
05-Sep-2022 04:51:00.733 WARNING [main]
org.apache.tomcat.util.digester.SetPropertiesRule.begin Match
[Server/Service/Connector] failed to set property [ciphers] to
[SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384]


Regards,
Saicharan Burle


The error message / stack contains the relevant information:
The SSLHostConfig  element is missing in your server.xml , see example and 
documentation here: 

Re: Latest version url

2022-09-03 Thread Mark Thomas

Hi,

The short answer is no. You are going to have to parse something and 
then construct the URL from the result.


I can think of a couple of options.

1. https://tomcat.apache.org/doap_Tomcat.rdf
2. The download page
3. https://dlcdn.apache.org/tomcat/tomcat-10/

You might also be able to do something with a dummy Maven project and a 
dependency on org.apache.tomcat:tomcat and an appropriate version range.


Mark


On 03/09/2022 00:27, NH Rao wrote:

Greetings,

I am looking for a perma link or similar which won't go away and point to
latest version of tomcat for the currently supported major versions.
Official downloads page points to latest minor release of the major version
e.g. https://tomcat.apache.org/download-90.cgi and download links keep
changing.

Is there any way to get latest version link or latest version and then us
forming the url from tomcat website. We have scripts that download whatever
latest version available and run some tests and link keeps breaking.

Regards,

Niranjan



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



Re: [EXTERNAL] Re: How to setup Strict-Transport-Security in TOMCAT

2022-08-31 Thread Mark Thomas

On 31/08/2022 17:39, Yanhua Wusands wrote:

You are right, tomcat is sitting behind AWS LB, where is ssl enabled, once it 
is passed that, tomcat is set up to listen 8080.
If I understand you correctly, we will need to setup SSL in TOMCAT as well in 
order to have HSTS working, is it right?


No. That is not correct.

There are several options at this point. We need more information to 
identify the best one.


Is it true that all traffic seen by Tomcat must have been sent over TLS 
between the user agent and AWS LB?


Mark



-Original Message-
From: Mark Thomas 
Sent: Wednesday, August 31, 2022 11:21 AM
To: users@tomcat.apache.org
Subject: Re: [EXTERNAL] Re: How to setup Strict-Transport-Security in TOMCAT

You don't have any TLS connectors configured so the HSTS filter isn't going to 
do anything.

Given you access the server via port 443 but Tomcat is only listening on port 
8080 you must have a reverse proxy configured somewhere that is likely 
terminating the TLS.

You need to configure HSTS wherever the TLS is being terminated.

As an aside, you need to be *very* careful proxying secure traffic to an HTTP 
connector on Tomcat. I trust that you have the appropriate configuration in 
place (typically the RemoteIpValve) to ensure that Tomcat can correctly 
identify which traffic has been received via a secure channel and which via an 
insecure channel.

Mark


On 31/08/2022 16:10, Yanhua Wusands wrote:



  
  
  
  
  
  

  
  



-Original Message-
From: Mark Thomas 
Sent: Wednesday, August 31, 2022 11:03 AM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: How to setup Strict-Transport-Security in
TOMCAT

On 31/08/2022 15:36, Yanhua Wusands wrote:

We are using TOMCAT 9.0.40 on linux, and are trying setup 
Strict-Transport-Security per requirement from our security team.

We followed this note:
https://urldefense.com/v3/__https://knowledge.broadcom.com/external/a
r
ticle/226769/enable-http-strict-transport-security-hs.html__;!!Ec1O5i
y
8QcVh!GA40DCbCXd3AheMXejlVBzoCrxjPpYuD5q1tH5L4QY01vfZAZ-F5iLprImL0Qe5
h
TO4K-UbrvgSvSAepZe_e-U8$

Changed $CATALINA_HOME/conf/web.xml

With:

  

   httpHeaderSecurity

   
org.apache.catalina.filters.HttpHeaderSecurityFilter
i
lter-class>

   true



hstsEnabled

true





hstsMaxAgeSeconds

31556927



   

And uncommented:
   
   httpHeaderSecurity
   /*
   REQUEST
   

After we restarted TOMCAT APACHE, we still couldn't see 
Strict-Transport-Security using following curl cmd:

curl -i -s
https://urldefense.com/v3/__https://finerp-apps-dev02.test.advanceaut
o
.cloud/ords/apex_ext/r/advance-supplier-portal/home__;!!Ec1O5iy8QcVh!
G
A40DCbCXd3AheMXejlVBzoCrxjPpYuD5q1tH5L4QY01vfZAZ-F5iLprImL0Qe5hTO4K-U
b rvgSvSAepLuScW-A$  | grep -i Strict-Transport-Security

I am reaching out to see if there is any additional steps need to be done for 
setting up this security flag.


Please provide the Connector element(s) (with sensitive data like passwords 
masked) from your $CATALINA_BASE/conf/server.xml file.

Mark

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


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



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


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



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



Re: [EXTERNAL] Re: How to setup Strict-Transport-Security in TOMCAT

2022-08-31 Thread Mark Thomas
You don't have any TLS connectors configured so the HSTS filter isn't 
going to do anything.


Given you access the server via port 443 but Tomcat is only listening on 
port 8080 you must have a reverse proxy configured somewhere that is 
likely terminating the TLS.


You need to configure HSTS wherever the TLS is being terminated.

As an aside, you need to be *very* careful proxying secure traffic to an 
HTTP connector on Tomcat. I trust that you have the appropriate 
configuration in place (typically the RemoteIpValve) to ensure that 
Tomcat can correctly identify which traffic has been received via a 
secure channel and which via an insecure channel.


Mark


On 31/08/2022 16:10, Yanhua Wusands wrote:



 
 
 
 
 
 

 
 



-Original Message-
From: Mark Thomas 
Sent: Wednesday, August 31, 2022 11:03 AM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: How to setup Strict-Transport-Security in TOMCAT

On 31/08/2022 15:36, Yanhua Wusands wrote:

We are using TOMCAT 9.0.40 on linux, and are trying setup 
Strict-Transport-Security per requirement from our security team.

We followed this note:
https://urldefense.com/v3/__https://knowledge.broadcom.com/external/ar
ticle/226769/enable-http-strict-transport-security-hs.html__;!!Ec1O5iy
8QcVh!GA40DCbCXd3AheMXejlVBzoCrxjPpYuD5q1tH5L4QY01vfZAZ-F5iLprImL0Qe5h
TO4K-UbrvgSvSAepZe_e-U8$

Changed $CATALINA_HOME/conf/web.xml

With:

 

  httpHeaderSecurity

  
org.apache.catalina.filters.HttpHeaderSecurityFilter
lter-class>

  true



hstsEnabled

true





hstsMaxAgeSeconds

31556927



  

And uncommented:
  
  httpHeaderSecurity
  /*
  REQUEST
  

After we restarted TOMCAT APACHE, we still couldn't see 
Strict-Transport-Security using following curl cmd:

curl -i -s
https://urldefense.com/v3/__https://finerp-apps-dev02.test.advanceauto
.cloud/ords/apex_ext/r/advance-supplier-portal/home__;!!Ec1O5iy8QcVh!G
A40DCbCXd3AheMXejlVBzoCrxjPpYuD5q1tH5L4QY01vfZAZ-F5iLprImL0Qe5hTO4K-Ub
rvgSvSAepLuScW-A$  | grep -i Strict-Transport-Security

I am reaching out to see if there is any additional steps need to be done for 
setting up this security flag.


Please provide the Connector element(s) (with sensitive data like passwords 
masked) from your $CATALINA_BASE/conf/server.xml file.

Mark

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


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



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



Re: How to setup Strict-Transport-Security in TOMCAT

2022-08-31 Thread Mark Thomas

On 31/08/2022 15:36, Yanhua Wusands wrote:

We are using TOMCAT 9.0.40 on linux, and are trying setup 
Strict-Transport-Security per requirement from our security team.

We followed this note:
https://knowledge.broadcom.com/external/article/226769/enable-http-strict-transport-security-hs.html

Changed $CATALINA_HOME/conf/web.xml

With:



 httpHeaderSecurity

 
org.apache.catalina.filters.HttpHeaderSecurityFilter

 true



hstsEnabled

true





hstsMaxAgeSeconds

31556927



 

And uncommented:
 
 httpHeaderSecurity
 /*
 REQUEST
 

After we restarted TOMCAT APACHE, we still couldn't see 
Strict-Transport-Security using following curl cmd:

curl -i -s 
https://finerp-apps-dev02.test.advanceauto.cloud/ords/apex_ext/r/advance-supplier-portal/home|
 grep -i Strict-Transport-Security

I am reaching out to see if there is any additional steps need to be done for 
setting up this security flag.


Please provide the Connector element(s) (with sensitive data like 
passwords masked) from your $CATALINA_BASE/conf/server.xml file.


Mark

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



Re: Tomcat Native and macOS 10.15.7

2022-08-23 Thread Mark Thomas

On 23/08/2022 14:12, Thad Humphries wrote:

I'm trying to understand a problem I'm having with Tomcat Native since
moving from 1.2.x to 2.0.

For several years I have been running Tomcat 9.0.12 in Eclipse and 9.0.37
for localhost on my home and office Mac Mini's with macOS 10.15.7 Catalina.
Both use OpenJDK 8 from Amazon. To support development I have a self-signed
certificate and until recently used Tomcat Native 1.2.x installed with
Homebrew. I added `CATALINA_OPTS="-Xmx1024m
-Djava.library.path=/usr/local/opt/tomcat-native/lib"` to my bin/setevn.sh

With this configuration I was able to the
connector org.apache.coyote.http11.Http11AprProtocol with UpgradeProtocol
for org.apache.coyote.http2.Http2Protocol

Recently Homebrew replaced Tomcat Native 1.2.x with 2.0.1. Since then when
Tomcat starts I see in catalina.out "The Apache Tomcat Native library which
allows using OpenSSL was not found on the java.library.path:
[/usr/local/opt/tomcat-native/lib]". I've had to switch my development to
connector org.apache.coyote.http11.Http11NioProtocol (I need SSL for my
client-server setup).

I've tried using a Tomcat Native 2 I built myself, but get the same "not
found on the java.library.path" message. I tried using a Tomcat Native
1.2.35 I built myself but got the following stacktrace in catalina.out

23-Aug-2022 03:07:29.541 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded Apache
Tomcat Native library [1.2.35] using APR version [1.7.0].
23-Aug-2022 03:07:29.541 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR
capabilities: IPv6 [true], sendfile [true], accept filters [false], random
[true].
23-Aug-2022 03:07:29.541 INFO [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL
configuration: useAprConnector [false], useOpenSSL [true]
23-Aug-2022 03:07:29.544 SEVERE [main]
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Failed to
initialize the SSLEngine.
org.apache.tomcat.jni.Error: 70023: This function has not been implemented
on this platform
at org.apache.tomcat.jni.SSL.initialize(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:289)
at
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:136)
at
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
at
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:135)
at org.apache.catalina.startup.Catalina.load(Catalina.java:690)
at org.apache.catalina.startup.Catalina.load(Catalina.java:712)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:302)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:472)

What is the issue I'm seeing and how might it be corrected if I want to run
Tomcat Native for the APR protocol?


You can't.

The APR connector has been deprecated and has been removed in Tomcat 
10.1.x onwards.


Tomcat Native 2.0.x does not support the APR connectors.

You need to switch to NIO or NIO2. If you want to use OpenSSL for TLS 
then you can do so (you'll need Tomcat Native 2.0.x and OpenSSL). Look 
at the docs for the sslImplementationName attribute.



BTW, this is not critical to me; I can live with NIO. However I'm the *only*
person on this team who pays any attention to Tomcat, and I may be having
to explain this to my coworkers and our boss. Others use a mix of Linux,
Windows, and Mac. Most don't use SSL internally but some use the AJP
connector for Apache, and IIRC that needs Tomcat Native, too.


AJP does not require APR/Native. There are NIO and NIO2 implementations 
for AJP.


Mark

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



Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

2022-08-23 Thread Mark Thomas

On 23/08/2022 02:45, Terence M. Bandoian wrote:
Recently, message attachments that appear blank in my e-mail client have 
been included in the Tomcat users mailing list digest.  Some users' 
messages are normally not blank (e.g. Tomcat committers and others). 
Messages from other users are.  Replies to "blank" messages by users 
whose messages are not blanked include the original message.  My e-mail 
client has not changed.


This message is a forward of a digest in which all of the message 
attachments appear blank in my e-mail client.  They also appear blank in 
GMail.  However, the attachments do include data which may be accessed 
by viewing the message source.


Has anyone else experienced this?


I haven't. I use Thunderbird as an email client.


Is this something that can be fixed by anyone on this list?


I don't think it is purely a list level configuration issue. I suspect a 
combination sender's email client, list server behaviour (possibly 
digest related) and receiver's email client.


What I would recommend is sending emails in plain text ("proper" plain 
text - not a plain text part in a multi-part message).



Should it be reported on the Tomcat bugzilla or somewhere else?


If you can show that the ASF list software is violating a relevant RFC 
then you can raise an issue with the ASF infrastructure team via the ASF 
Jira instance. That said, my experience is that it is email clients that 
tend to play fast and loose with the RFCs.


In addition, I have been unable to send e-mail to 
users@tomcat.apache.org from tere...@tmbsw.com which I have used on this 
list since at least 2005.  I receive the following error reply:


I've checked the list subscription and you appear to be listed twice. 
I'm not sure if that is causing issues so I have removed one of the 
subscriptions.


Mark





Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address or a subscriber address or an 
address in LDAP.


Has something changed?  Do I need to reconfigure my mail server?  If so, 
in what way?


-Terence Bandoian


 Forwarded Message 
Subject: users Digest 17 Aug 2022 09:26:06 - Issue 14393
Date: 17 Aug 2022 09:26:06 -
From: users-digest-h...@tomcat.apache.org
Reply-To: Tomcat Users List 
To: users@tomcat.apache.org




users Digest 17 Aug 2022 09:26:06 - Issue 14393

Topics (messages 275525 through 275527)

Re: Getting error on Tomcat Start
275525 by: Mohan T
275526 by: Thomas Meyer
275527 by: Mohan T

Administrivia:

-
To post to the list, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-digest-h...@tomcat.apache.org

--





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


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



Re: Difference between versions

2022-08-23 Thread Mark Thomas

On 23/08/2022 00:36, Alex wrote:

Dear Mohan.

your E-Mail address is invalid!

moha...@ramco.com.INVALID


That isn't something the OP has done. That change is made by the ASF 
mail servers else many subscribers won't receive list emails.


https://blogs.apache.org/infra/search?q=munging



That does not helps to support you.


Just reply to the list and the OP will see the response.

Mark



Regards

Alex

On 22.08.22 16:17, Alex wrote:

Hi Mohan.

On 21.08.22 04:45, Mohan T wrote:

Dear All,

Just want to know if there are any major differences between the 
below tomcat versions.


Server version
Apache Tomcat/8.5.35

Server built:
Nov 3 2018 17:39:20 UTC
unknown
Server number:
8.5.35.0
8.5.x
Status
Working fine
Error
Error message
No error message .
[AD Thread Pool-Global1] 
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading 
Illegal access: this web application instance has been stopped 
already. Could not load 
[org.springframework.context.ApplicationContextInitializer]. The 
following stack trace is thrown for debugging purposes as well as to 
attempt to terminate the thread which caused the illegal access.
java.lang.IllegalStateException: Illegal access: this web application 
instance has been stopped already. Could not load 
[org.springframework.context.ApplicationContextInitializer]. The 
following stack trace is thrown for debugging purposes as well as to 
attempt to terminate the thread which caused the illegal access


When we deploy a application it throws error. Is there any reason 
because of the tomcat version.


Have you read the answer from Thomas 
https://lists.apache.org/thread/tdqx7pn7g269dyhv13gtrf5gx3myvx7f ?


Looks like you have answered your own question.

https://lists.apache.org/thread/0y0ch2qxzwzoq6rny1zr2q4h3g7gr01y

```
In one of the logs I could see the below error message .

org.apache.catalina.core.ApplicationContext.log
No Spring WebApplicationInitializer types detected on classpath
```

Have you asked the Application Development People how to deploy there 
Application on tomcat?


There are several hits in internet search engines for the log message.

https://html.duckduckgo.com/html?q=No%20Spring%20WebApplicationInitializer%20types%20detected%20on%20classpath 



Maybe some of the hits may solve your topic.



Thanks

Mohan


Regards
Alex

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



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



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



Re: Find the effective classpath in a spring webapp's Controller

2022-08-22 Thread Mark Thomas

On 22/08/2022 18:56, anjan bacchu wrote:

Hi there,

   I have a Controller in a spring webapp deployed to tomcat as a .war
file(this is not a boot app).

I have this code in the Controller

this.getClass().getClassLoader().getResourceAsStream(licenseFile)


The licenseFile is a 3rd party license file in our artifactory repository
and gets deployed by the gradle build to the WEB-INF\lib directory.

As expected, this licenseFile is not accessible to the Controller and this
fails.

2 Questions

1) How do I find the effective classpath for this webapp at runtime ?  (I
read the howto at
https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html )

2) Is there a way to read this licenseFile in the WEB-INF\lib directory
from the Controller ?


ServletContext.getResource("/WEB-INF/lib/licenseFile");

Mark

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



Re: Simple SSL question

2022-08-11 Thread Mark Thomas

On 11/08/2022 22:00, Peter Kreuser wrote:




What would be useful would be one sample how to transfer a simple "old" config 
to SSLHostConfig.
That would take away the fear to get going. In another thread I said, that it 
may be a lot of work to migrate a lot of tomcat instances. But I guess most 
people would only need a single SSLHostConfig  to add to their one connector...


Just configure the StoreConfigListener

https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html#StoreConfig_Lifecycle_Listener_-_org.apache.catalina.storeconfig.StoreConfigLifecycleListener

When that saves the current config it will use the SSLHostConfig style.

Mark

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



Re: Simple SSL question

2022-08-10 Thread Mark Thomas

On 10/08/2022 19:22, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ok, I'm asking a rather simple, stupid (in my opinion) question, but here goes:

What is the best practice form of connector for SSL. Is it the old-school coyote 
connector or the connector with the  section?




The old style isn't supported in Tomcat 10.0.x onwards.


Are the two interchangeable, or does the SSLHostConfig one rely on openssl and 
won't work without it? The documentation is confusing me on a hump day 
afternoon.


They are interchangeable. However, if you want to configure TLS virtual 
hosting with SNI you'll need to use SSLHostConfig.


Both approaches can be used with JSSE and OpenSSL based TLS implementations.

Mark





Thanks,

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

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

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

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




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



Re: End user files uploaded to sftp getting stored in tomcat root directory

2022-08-09 Thread Mark Thomas

This will always be an application issue.

Mark


On 09/08/2022 09:41, Farash Ahamad wrote:

Dear All,

I am observing there and several documents (pdf, png, jpeg, etc) which the
end user uploads in the application getting stored in tomcat / directory.

I would like to understand whether this is a bug in the application code or
in tomcat.

Application based on: Java Spring Boot 2.1.3
Tomcat version: 9.0.41
OS Version: RHEL 7.9
Document Destination: SFTP server (Unified gluster FS through Serv-U)

Appreciate your help.

Thanks & Regards,
Farash Ahamad



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



Re: Error during startup

2022-08-08 Thread Mark Thomas

On 08/08/2022 14:21, Joey Cochran wrote:

Make sure /bin/tomcat-juli.jar is set to 755 (chmod 755 tomcat-juli.jar)


That suggestion is completely unrelated to the problem the OP is reporting.


-Original Message-
From: Mohan T 
Sent: Monday, August 8, 2022 2:26 AM
To: Tomcat Users List 
Subject: [EXTERNAL] RE: Error during startup

We have added the contents under grant section.

Still we are getting the error message.



It looks like you are adding some sort of agent to instrument the JVM.

Java security manager permissions are associated specific JAR files. Han 
Li's suggestion was correct if the problem you are seeing is in 
application code (i.e. part of the web application under WEB-INF/lib or 
WEB-INF/classes).


If this is an agent then the JAR won't be in the web application. Where, 
exactly, is the JAR that contains the agent you are trying to use?


Mark




Error in Full Agent Registration Info Resolver reading environment 
variable/system property
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" 
"getenv.")
 at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
 at 
java.security.AccessController.checkPermission(AccessController.java:884)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 at java.lang.System.getenv(System.java:894)
 at 
com.singularity.ee.util.system.SystemUtils.getenv(SystemUtils.java:49)
 at 
com.singularity.ee.agent.resolver.ADefaultResolver.getProperty(ADefaultResolver.java:44)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.shouldCreateAgentInfoIfMissing(FullAgentRegistrationInfoResolver.java:83)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.(FullAgentRegistrationInfoResolver.java:72)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.(FullAgentRegistrationInfoResolver.java:60)
 at 
com.singularity.ee.agent.appagent.kernel.AppTierNodeDeterminerDelegate.executeGenericFunction(AppTierNodeDeterminerDelegate.java:260)
 at 
com.singularity.ee.agent.appagent.kernel.AppTierNodeDeterminer.executeGenericFunction(AppTierNodeDeterminer.java:128)
 at 
com.singularity.ee.agent.appagent.AgentEntryPoint.getAppTierNodeFromLib(AgentEntryPoint.java:1735)
 at 
com.singularity.ee.agent.appagent.AgentEntryPoint.determineAppAgentVersionToUse(AgentEntryPoint.java:1549)
 at 
com.singularity.ee.agent.appagent.AgentEntryPoint.premain(AgentEntryPoint.java:557)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at 
sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
 at 
sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:401)
Full Agent Registration Info Resolver found system property 
[appdynamics.agent.nodeName] for node name [Tomcat_iaasa7924_base0]
Full Agent Registration Info Resolver using selfService [false]
Full Agent Registration Info Resolver using selfService [false]
Full Agent Registration Info Resolver using ephemeral node setting [false]
Full Agent Registration Info Resolver using application name 
[ILAS-NonProd_34995]
Error in Full Agent Registration Info Resolver reading environment 
variable/system property
java.security.AccessControlException: access denied ("java.lang.RuntimePermission" 
"getenv.")
 at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
 at 
java.security.AccessController.checkPermission(AccessController.java:884)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 at java.lang.System.getenv(System.java:894)
 at 
com.singularity.ee.util.system.SystemUtils.getenv(SystemUtils.java:49)
 at 
com.singularity.ee.agent.resolver.ADefaultResolver.getProperty(ADefaultResolver.java:44)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.getNodeNameFromJavaAgentArg(FullAgentRegistrationInfoResolver.java:387)
 at 
com.singularity.ee.agent.resolver.FullAgentRegistrationInfoResolver.run(FullAgentRegistrationInfoResolver.java:252)
 at 
com.singularity.ee.agent.appagent.kernel.AppTierNodeDeterminerDelegate.getAppTierNode(AppTierNodeDeterminerDelegate.java:150)
 at 
com.singularity.ee.agent.appagent.kernel.AppTierNodeDeterminer.getAppTierNode(AppTierNodeDeterminer.java:83)
 at 
com.singularity.ee.agent.appagent.AgentEntryPoint.getAppTierNodeFromLib(AgentEntryPoint.java:1751)
 at 

Re: TCP timestamp vulnerability -- any insights on how this relates to Tomcat?

2022-08-06 Thread Mark Thomas



5 Aug 2022 23:37:22 James H. H. Lampert 
:


Today is the first time I heard of such a thing as a "TCP timestamp 
vulnerability." It seems a bit overblown to me, especially for a Tomcat 
server running on an AS/400.


Can anybody share any insights about how this vulnerability relates to 
Tomcat?


It doesn't.

This is a a network be stack/ OS issue.

The attacks I could find related to the issue were all information 
disclosure style issue that could help target other attacks.


I'd make sure the OS was kept fully patched and not worry about this 
issue.


Mark

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



Re: Tomcat is Automatically Getting Stopped Frequently

2022-08-03 Thread Mark Thomas
Tomcat won't be shutting itself down. Something external must be 
stopping the process.


Check the OS logs. This sounds like the Linux OOM killer.

Note: Attachments rarely make it to the list. If you need to share 
attachments, use a file sharing service.


Mark


On 03/08/2022 09:12, Prasenjit Dey wrote:

Tomcat Version: 8.5.81.0

Operating System: Ubuntu 20.04 LTS

RAM: 8gb

Java Version: 1.8.0_312

Architecture: 64Bit

Hi,

I am facing a problem regarding our application hosted in Tomcat. Our 
infrastructure is on Azure Cloud. We have hosted our application in 
Tomcat on a virtual machine deployed from Azure. After few hours of 
usage, we are experiencing that the Tomcat is going down automatically 
and we are not able to browse the application. From the memory point of 
view we have seen that when the problem is occurring then Tomcat service 
is using 1.4GB of memory. Attaching the Tomcat logs and server.xml for 
your reference. Please feel free to connect with us if you need any 
additional information.


*Thanks & Regards,*

*Prasenjit Dey | Team Leader - Testing | Kovair Software*

*Ph: +91.33. 40657016 Ext. 240 | **prasanjit...@kovair.com* 



*URL:**http://www.kovair.com* 



PPlease consider the environment before printing this email



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


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



Re: Tomcat 9.0.33 for ubuntu 20.04

2022-08-01 Thread Mark Thomas

On 01/08/2022 17:00, Rhea Moubarak wrote:

Hello,

There was a bug (64189 : https://bz.apache.org/bugzilla/show_bug.cgi?id=64189 ) 
that was fixed in Tomcat 9.0.32, however this update was never released. So 
would I find the fix is the version tomcat 9.0.33?


Yes.


If no, then how can I know where was this bug was fixed?


N/A


If yes, then is it possible to integrate TOMCAT 9.0.33 in the official repo of 
Ubuntu 20.04?


That would be a question for Ubuntu support. The Apache Tomcat project 
has no control over downstream distributions.


Mark

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



[ANN] Apache Tomcat 10.0.23 available

2022-07-26 Thread Mark Thomas

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

This release is targeted at Jakarta EE 9.

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


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

The notable changes compared to 10.0.22 include:

- Implement support for repeatable builds

- Update the packaged version of the Tomcat Native Library to 1.2.35.
  This includes Windows binaries built with with OpenSSL 1.1.1q.

- Fix CVE-2022-34305, a low severity XSS vulnerability in the Form
  authentication example

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

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

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

Enjoy!

- The Apache Tomcat team

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



Re: AW: [ANN] Apache Tomcat 9.0.65 available

2022-07-21 Thread Mark Thomas



21 Jul 2022 07:32:20 Thomas Hoffmann (Speed4Trade GmbH) 
:



Hello,

I saw just a little typo I think.
In the changelog: jmvRoute --> jvmRoute


Thanks.

Should've fixed in git now.

Mark




Thanks!
Thomas


-Ursprüngliche Nachricht-
Von: Rémy Maucherat 
Gesendet: Mittwoch, 20. Juli 2022 23:18
An: Tomcat Developers List ; Tomcat Users List
; annou...@tomcat.apache.org;
annou...@apache.org
Betreff: [ANN] Apache Tomcat 9.0.65 available

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

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

Apache Tomcat 9.0.65 is a bugfix and feature release. The notable 
changes

compared to 9.0.64 include:

- Implement support for repeatable builds.

- Update the packaged version of the Tomcat Native Library to 1.2.35.
   This includes Windows binaries built with OpenSSL 1.1.1q.

- Fix CVE-2022-34305, a low severity XSS vulnerability in the Form
   authentication example.

Along with lots of other bug fixes and improvements.

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


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

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

Enjoy!

- The Apache Tomcat team

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



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


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



[ANN] Apache Tomcat 10.1.0-M17 (beta) available

2022-07-20 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 10.1.0-M17 (beta).

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

The Jakarta EE specifications implemented by Tomcat 10.1.x are now final 
and Tomcat's implementation of those specifications is complete.


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


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


- Implement support for repeatable builds

- Update the packaged version of the Tomcat Native Library to 2.0.1.
  This includes Windows binaries built with with OpenSSL 3.0.5.

- Update experimental Panama modules with support for OpenSSL 3.0+.
  OpenSSL 1.1 remains supported.

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

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

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

Enjoy!

- The Apache Tomcat team

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



Re: AW: AW: AW: AW: Filehandle left open when using sendfile

2022-07-20 Thread Mark Thomas



20 Jul 2022 12:09:46 Thomas Hoffmann (Speed4Trade GmbH) 
:



Hello Mark,

I briefly want to ask whether the internal discussion about the open 
JVM file handle when using sendfile/Memory-Mapped-Files

resulted in any conclusions?


We opted to document the risk of file locking and left the code 
unchanged.


Mark




Thanks in advance!
Thomas


-Ursprüngliche Nachricht-
Von: Mark Thomas 
Gesendet: Montag, 20. Juni 2022 22:13
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AW: Filehandle left open when using sendfile

On 20/06/2022 11:39, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello Mark,

thanks for your reply!


-Ursprüngliche Nachricht-
Von: Mark Thomas 
Gesendet: Montag, 20. Juni 2022 12:06
An: users@tomcat.apache.org
Betreff: Re: AW: AW: Filehandle left open when using sendfile

On 16/06/2022 19:58, Thomas Hoffmann (Speed4Trade GmbH) wrote:




In the meantime I stumbled upon this bug-Report:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154
So maybe the problem lies even deeper.
Similar description here:
https://cemerick.com/blog/2006/08/30/memory-mapping-files-in-java-

caus

es-problems.html

Some ppl suggest to use java.lang.ref.Cleaner or don’t use Memory-

Mapped files under Windows.

I don’t know if there are other solutions.


Your research looks to be exhaustive. I can't find any better ideas.

Using the java.lang.ref.Cleaner looks to be a viable option. We know
when the mapped file is no longer being used. However, that requires
Java 12 onwards.

This is only going to be required if the file locking is an issue. 
In
read-only scenarios or when using an OS other than Windows it won't 
be

an issue.


So, what do we want to do?

1. Disable sendfile for HTTP/2 if running on Windows?

2. Document the potential issues with sendfile + HTTP/2 + Windows if
resources are not read-only?

3. Use the JreCompat mechanism to clear the references if possible:
 - if running on Windows
 - on all OSes
 - if enabled via configuration

Something else?

Mark


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


I did some further searching on this topic.
Several posts disregard using java.lang.ref.Cleaner because if the 
buffer is

used afterwards, it will crash the VM. But if used carefully it works.

If we use this option, it should be possible to use it appropriately 
carefully.



About your suggestions:
2) Documenting would be helpful, if lock can't be prevented.
  I also found documentation at e.g.


https://docs.oracle.com/javase/9/docs/api/java/nio/channels/FileChannel.h
tml#map-java.nio.channels.FileChannel.MapMode-long-long-
  " The buffer and the mapping that it represents will remain 
valid until

the buffer itself is garbage-collected."

Which is essentially the problem. Using the Cleaner would clean up the
reference sooner.

3) As JreCompat is a bit risky, enabling via config sounds safe to 
me.


JreCompat is perfectly safe. The jdk.internal.misc.Unsafe API is where 
the
risk is and this is primarily the risk of the crash mentioned above 
that we

should be able to avoid.


Some other (theoretical?) options:
4) In an older version of Tomcat native lib there seemed to be a 
native

Implementation of MMap: https://tomcat.apache.org/tomcat-10.0-
doc/api/org/apache/tomcat/jni/Mmap.html

   I read that this was an alternative to the Java memory mapped
file.  But it was removed in newer versions. Maybe it can be
resurrected for this case and used if native lib is available(?)


Sorry, no. We are moving away from the native library. Eventually we 
will just

use project Panama to wrap OpenSSL. Until then, we are removing
everything that isn't required to support the use of OPenSSl with NIO 
and

NIO2.

The primary reason for this is stability.


5) Instead of FileChannel.map maybe a normal ByteBuffer with
FileChannel.read(buffer) can be used (?)


That is worth considering. The other sendfile implementations don't 
use a

memory mapped file.

I'll start a discussion on the dev list.


One remaining question:
I didn’t find FileChannel.map in the other connectors. Is

Http2AsyncUpgradeHandler the only occurrence?

In the main code base, yes. There is another usage in the test code 
but that is

less of a concern.

Mark

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



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


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



Re: Tomcat 9.0.62: Setting STRICT_SERVLET_COMPLIANCE to true breaks Tomcat Single Sign On

2022-07-14 Thread Mark Thomas

Hi,

It looks like the documentation needs a further update. 
STRICT_SERVLET_COMPLIANCE also affects the CookieProcessor instances. 
Specifically, look at the forwardSlashIsSeparator attribute of the 
LegacyCookieProcessor.


https://tomcat.apache.org/tomcat-9.0-doc/config/cookie-processor.html

That system property only affects / in Cookie names.

Mark


On 14/07/2022 21:13, Wenshiuan Tang wrote:

---
Description
---
I have a web app that is a collection of a few web apps, with a structure
like:

- apache-tomcat
   - myWebSite
 - webapps
   - web app #1 (login)
   - web app #2
   - ... ...
   - web app #X

I use Tomcat SingleSignOn valve for moving around the web apps with one
authentication. However, Tomcat single sign on stop working after I set the
parameter STRICT_SERVLET_COMPLIANCE to true.

I tried to look up the use of STRICT_SERVLET_COMPLIANCE with Tomcat 9 but
didn't find much info related to the cookie issue I encountered.


-
Setup
-
1. Tomcat 9.0.62
2. Java: OpenJDK 8u332
3. OS: Red Hat Enterprise Linux 8.4
4. Browser Client: Firefox (102.0.1, 64-bit)/Chrome (103.0.5060.114,
64-bit).
5. The Host config (partial) in Tomcat server.xml:


 
... ...



---
Details
---
The behavior is supposed to be:
1. User accesses the web app and gets redirected to the login page.  The
login is handled by web app #1.
2. After successful login, user is supposed to be redirected to a page that
is handled by web app #2.

What actually happened is:
1. User accesses the web app and gets redirected to the login page.  The
login is handled by web app #1.
2. After successful login, user gets redirected to a page that is handled
by web app #2. However, the single sign on cookie was not sent in the
request to the page handled by web app #2.
3. So the user gets redirected to the login page handled by web app #1.
4. The single sign on cookie was present in the request to the login page
handled by web app #1. So it does not ask the user to login again. Then the
user gets redirected to the page handled by web app #2.
5. It keep repeating the steps between Steps 2-4.

The observations are:
1. If the parameter STRICT_SERVLET_COMPLIANCE is false (default):
(a) the single sign on cookie is present in the requests to the web app(s)
so no additional authentication is required when moving around web apps
after successful login.
(b) The path in the cookie is root web app that looks like "/" in the
browser developer tool.

2. If the parameter STRICT_SERVLET_COMPLIANCE is true:
(a) the signle sign on cookie is present ONLY in the requests to the web
app #1 that handles the login authentication.
(b) the path in the cookie is root web app but with additional
double-quotes "\"/\"".

This issue is observed in Firefox (102.0.1, 64-bit) and Chrome
(103.0.5060.114, 64-bit).

According to Tomcat 9 documentation for STRICT_SERVLET_COMPLIANCE at:
https://tomcat.apache.org/tomcat-9.0-doc/config/systemprops.html#Security

Setting the parameter STRICT_SERVLET_COMPLIANCE affects a number of other
parameters. So I tried to set the affected parameters back to default after
setting STRICT_SERVLET_COMPLIANCE as true like below:

   -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
-Dorg.apache.catalina.core.ApplicationContext.GET_RESOURCE_REQUIRE_SLASH=false
-Dorg.apache.catalina.core.ApplicationDispatcher.WRAP_SAME_OBJECT=false
-Dorg.apache.catalina.core.StandardHostValve.ACCESS_SESSION=false
-Dorg.apache.catalina.session.StandardSession.ACTIVITY_CHECK=false
-Dorg.apache.catalina.session.StandardSession.LAST_ACCESS_AT_START=false
-Dorg.apache.tomcat.util.http.ServerCookie.STRICT_NAMING=false
-Dorg.apache.tomcat.util.http.ServerCookie.ALWAYS_ADD_EXPIRES=true
-Dorg.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR=false

In theory, that would negate the affect from STRICT_SERVLET_COMPLIANCE
being true. However, the behavior is the same- Tomcat single sign on still
breaks.

I compared the documentation about STRICT_SERVLET_COMPLIANCE between Tomcat
8 (at
https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html#Security)
and Tomcat 9. I found:

For Tomcat 8, 8 system properties will be affected by
STRICT_SERVLET_COMPLIANCE being true.

For Tomcat 9, 6 system properties will be affected by
STRICT_SERVLET_COMPLIANCE being true (no
org.apache.tomcat.util.http.ServerCookie.ALWAYS_ADD_EXPIRES and
org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR).

In Tomcat 8 documentation, it notes:
"Note that changing a number of the above defaults is likely to break the
majority of systems as some browsers are unable to correctly handle the
cookie headers that result from a strict adherence to the specifications.
Defaults, regardless of whether or not they have been changed by setting
org.apache.catalina.STRICT_SERVLET_COMPLIANCE can always be overridden by
explicitly setting the appropriate system property or element attribute."

There is no such note in Tomcat 9 documentation. 

Re: Apache Tomcat 8.5.82 Release Date

2022-07-13 Thread Mark Thomas

On 13/07/2022 10:46, Wai Siang, Chu wrote:

Dear Apache Tomcat Team,

We are aware there is a vulnerability found in the latest 8.5.xx version.

*Low: Apache Tomcat XSS in examples web application* CVE-2022-34305


Hence, may we check is there an estimated timeline for the *Apache Tomcat
8.5.82* release date?


Why?

Have you reviewed the vulnerability? It is a XSS in the examples app. 
The examples app should never be deployed in a production environment. 
Hence this vulnerability should be a non-issue for (nearly?) all users.


Like all currently supported Tomcat versions, 8.5.x is released on a 
roughly monthly cycle. The July release for 8.5.x hasn't started yet so 
I'd expect the release later this month.


If you want to follow release planning more closely, then that is 
discussed on the dev list.


Mark





Thank you.

Regards,
Wai Siang

D: -
M: (65) 9821 0409
T: (65) 6837 2822
F: (65) 6756 3839
E : waisi...@toppanecquaria.com

11 Toa Payoh Lorong 3
#02-31 Block C, Jackson Square
Singapore 319579

Toppan Ecquaria Pte. Ltd.
Company Registration No: 199806305H

www.toppanecquaria.com

https://www.linkedin.com/company/toppan-ecquaria/




STRICTLY CONFIDENTIAL - This message, its contents and any files
transmitted with it are intended SOLELY for the addressee(s) and may be
legally privileged and/or confidential. Access by any other party is
unauthorised without the expressed written permission of the sender. If you
have received this message in error, you may not copy or use the contents,
attachments or information in any way. Please destroy it and contact us
immediately via e-mail return or by telephone at (65) 68372822. This
message has been prepared using information believed by the author to be
reliable and accurate, but Toppan Ecquaria Pte. Ltd. and the Toppan Group
of Companies ("Toppan") makes no warranty as to its accuracy or
completeness. Toppan does not accept responsibility for changes made to
this message after it was sent.



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



[ANN] Apache Tomcat Native 2.0.1 released

2022-07-13 Thread Mark Thomas

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

The key features of this release are:

- JNI API has been reduced to just that required to support Tomcat's
  OpenSSL based TLS implementation. The APR/native connector is no
  longer supported in this branch.

- The minimum supported versions have been increased to OpenSSL 3.0.x,
  Apache APR 1.7.x, Java 11, Windows 7 / Server 2008 R2

- The windows binaries in this release have been built with OpenSSL
  3.0.5

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


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

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

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


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



Re: Getting SSL Working on Tomcat9

2022-07-11 Thread Mark Thomas

On 11/07/2022 14:56, George Sexton wrote:

Mark,

Thanks for looking.

If I specify the value for defaultSSLHostConfigName, I still get 
/SSLHostConfig attribute certificateFile must be defined shen using an 
SSL connector/.


If I remove the hostName from the SSLHostConfig (or specify 
hostName="_default_"), I get:


ACK.

Because useServerCipherSuitesOrder is present on the Connector, you 
effectively have a SSLHostConfig element for "_default_" with just that 
setting.


Try removing useServerCipherSuitesOrder from the Connector and adding 
honorCipherOrder to the SSLHostConfig element.


Mark

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



ApacheCon

2022-07-11 Thread Mark Thomas

All,

This a is a reminder that there are two Apache conferences coming up 
that will be featuring presentations about Apache Tomcat.


ApacheCon Asia 2022
July 29-31
Virtual
More details: https://www.apachecon.com/acasia2022/index.html

ApacheCon North America 2022
October 3-6
New Orleans, USA
More details: https://www.apachecon.com/acna2022/index.html

Registration is now open for both events.


We also have slides available for previous presentations on the Tomcat 
website: Many of them also have audio and/or video recordings available.


https://tomcat.apache.org/presentations.html

Mark

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



[ANN] Apache Tomcat Migration tool for Jakarta EE 1.0.1

2022-07-11 Thread Mark Thomas

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Migration Tool for Jakarta EE 1.0.1

Apache Tomcat Migration Tool for Jakarta EE is an open source software
tool for migrating binary web applications (WAR files) and other binary
artefacts from Java EE 8 to Jakarta EE 9.

The notable changes since 1.0.0 include:

- Add support for .groovy files

- Better support for non-standard archives

- Numerous library updates

Please refer to the change log for the complete list of changes:
https://github.com/apache/tomcat-jakartaee-migration/blob/master/CHANGES.md

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

Enjoy!

- The Apache Tomcat team


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



Re: Getting SSL Working on Tomcat9

2022-07-11 Thread Mark Thomas

On 11/07/2022 02:30, George Sexton wrote:

I'm trying to configure SSL for Tomcat 9 and I'm not having any luck.




Caused by: java.io.IOException: SSLHostConfig attribute certificateFile 
must be defined when using an SSL connector
     at 
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:312)




Looking at the docs, it doesn't appear that certificateFile is an 
attribute of SSLHostConfig.


That looks like a message string that need to be updated to reference 
the Certificate element instead. I'll look into that.




/The following NIO and NIO2 SSL configuration attributes have been 
deprecated in favor of the default //SSLHostConfig 
//element 
with the //|hostName|//of //|_default_|//. If this //SSLHostConfig 
//element 
is not explicitly defined, it will be created.. /


Additionally, I'd like to use SNI for multiple certs, so that will 
require an SSLHostConfig I think. Can anyone give me an idea of what I'm 
doing wrong?


From further up in the docs:


Each secure connector must define at least one SSLHostConfig. The names 
of the SSLHostConfig elements must be unique and one of them must match 
the defaultSSLHostConfigName attribute of the Connector.



You haven't specified an explicit defaultSSLHostConfigName so the 
default value of "_default_" is being used. The error message you are 
seeing is complaining that the SSLHostConfig for "_default_" is incomplete.


Either adding the defaultSSLHostConfigName="*.mydomain.com" attribute to 
the Connector element or removing the hostName attribute from the 
SSLHostConfig element should fix it.


Mark

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



  1   2   3   4   5   6   7   8   9   10   >