Re: EOL - Tomcat versions

[i...@flyingfischer.ch]

https://endoflife.date/tomcat

Am 08.01.24 um 07:39 schrieb Deshmukh, Kedar:

Hello,

Could you please throw some light on Tomcat versions and its EOL plan?


   1.  8.5.X
   2.  9.0.X
   3.  10.0.X
   4.  10.1.X

This information would be very critical for us to move forward.


Thanks,
Kedar



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

Re: Tomcat 9.0.81 Degraded ssl performance

[i...@flyingfischer.ch]

Am 12.10.23 um 03:01 schrieb Paul Zepernick:

Thank you Chuck

Paul

From: Chuck Caldarale 
Sent: Wednesday, October 11, 2023 8:54:59 PM
To: Tomcat Users List 
Subject: Re: Tomcat 9.0.81 Degraded ssl performance

NOTICE: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On Oct 11, 2023, at 19:44, Paul Zepernick  
wrote:

Tomcat Version: 9.0.81
OS: Windows Server 2016

We recently patched one of our QA servers to test 9.0.81 and ran into 
performance issues.  Page loads that normally take 1-2 seconds are now taking 
50-60 seconds.  We were finally able to narrow the issue down to the SSL 
connector.  Adding an HTTP connector and bypassing ssl resolves the performance 
issue.  We have also tested rolling back to 9.0.80 with the same configuration 
and verified the issue does not exist.


This was due to a regression introduced in 9.0.81, as noted here: 
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D67670=05%7C01%7CPaul.Zepernick%40healthsmart.com%7C6873588541c945dc808a08dbcabde7eb%7C2ce547c5e80a40628a56f25adceefb52%7C0%7C1%7C638326689235160357%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=cCe%2BgFFBcYzUvnnA%2BYqv9A8koG0QxL2Xq9Om5Edo9%2BQ%3D=0

The problem has been fixed in 9.0.82 which is currently being voted on; release 
will likely occur in another day or two.

   - Chuck

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or intended recipient’s authorized agent, the reader is hereby
notified that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.


You may also set on the connector as a workaround

compression="off"

This will resolve the issue for the time being without the need to 
downgrade to an insecure version.



Markus




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

Re: Tomcat upgrade from 9.0.80 to 9.0.81

[i...@flyingfischer.ch]

Am 11.10.23 um 14:02 schrieb Alexander Veit:
Caused by: org.apache.http.ConnectionClosedException: Premature end of 
Content-Length delimited message body (expected: 4,999; received: 3,040)
    at 
org.apache.http.impl.io.ContentLengthInputStream.read(ContentLengthInputStream.java:178)
    at 
io.restassured.internal.util.IOUtils.toByteArray(IOUtils.java:30)
    at 
io.restassured.internal.http.GZIPEncoding$GZIPDecompressingEntity.getContent(GZIPEncoding.java:69)
    at 
org.apache.http.conn.BasicManagedEntity.getContent(BasicManagedEntity.java:85)
    at 
io.restassured.internal.http.HTTPBuilder.parseResponse(HTTPBuilder.java:546)
    at 
io.restassured.internal.RequestSpecificationImpl$RestAssuredHttpBuilder.super$2$parseResponse(RequestSpecificationImpl.groovy)

    at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
    at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

    at java.lang.reflect.Method.invoke(Method.java:498)
    at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)

    at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
    at 
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1268)
    at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:144)


Has anyone seen this? I will keep everyone posted after debugging more.


We have experienced the same problem with Tomcat 8.5.94.

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



Seems to be reported multiple times as this is blocking bug for 
upgrading to the last Tomcat version:



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

Markus

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

Change in behavior Tomcat 9.0.81

[i...@flyingfischer.ch]

Strange change in behavior, when updating to the latest Tomcat 9.0.81 
version:


Calling static files (.js / .css) from a server running Tomcat 9.0.81 
over httpclient now results in


org.apache.http.ConnectionClosedException: Premature end of 
Content-Length delimited message body (expected: 8’170; received: 1’927)


Downgrading the server running the webapp serving the static files to 
Tomcat 9.0.80 does not show the issue.


Has there been a change that triggers this error, related to the many 
security fixes in 9.0.81?


Thanks for considering.

Best regards
Markus

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

Re: [ANN] Apache Tomcat 8.5.77 available

[i...@flyingfischer.ch]

Am 17.03.22 um 14:15 schrieb Christopher Schultz:

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.77.
[...]

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

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

Enjoy!

- The Apache Tomcat team

May be a matter of seconds, but 
https://tomcat.apache.org/download-80.cgi still shows Version 8.5.76


Markus


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

Re: Native libraries not found?

[i...@flyingfischer.ch]

Am 23.02.22 um 09:12 schrieb Claude Brisson:

Hi.

After an upgrade from debian buster to debian bullseye, the APR native 
library stopped working:



Did you install libapr1 libapr1-dev libssl-dev before compiling?


Markus




# dpkg -l | ag tomcat
ii  libtcnative-1:amd64 1.2.26-1   amd64    
Tomcat native library using the Apache Portable Runtime
ii  libtomcat9-java 9.0.43-2~deb11u3   all  Apache 
Tomcat 9 - Servlet and JSP engine -- core libraries
ii  tomcat9 9.0.43-2~deb11u3   all  Apache Tomcat 
9 - Servlet and JSP engine
ii  tomcat9-common 9.0.43-2~deb11u3   all  Apache 
Tomcat 9 - Servlet and JSP engine -- common files


And the log shows:

[2022-02-23 07:58:19] [info] Server version name:   Apache 
Tomcat/9.0.43 (Debian)
[2022-02-23 07:58:19] [info] Server built:  Jan 4 1970 
19:03:34 UTC

[2022-02-23 07:58:19] [info] Server version number: 9.0.43.0
[2022-02-23 07:58:19] [info] OS Name:   Linux
[2022-02-23 07:58:19] [info] OS Version:    4.19.0-8-amd64
[2022-02-23 07:58:19] [info] Architecture:  amd64
[2022-02-23 07:58:19] [info] Java Home: /usr/lib/jvm/java-8-oracle/jre
[2022-02-23 07:58:19] [info] JVM Version:   1.8.0_171-b11
[2022-02-23 07:58:19] [info] JVM Vendor:    Oracle Corporation
[2022-02-23 07:58:19] [info] CATALINA_BASE: /var/lib/tomcat9
[2022-02-23 07:58:19] [info] CATALINA_HOME: /usr/share/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.awt.headless=true
[2022-02-23 07:58:19] [info] Command line argument: 
-Djdk.tls.ephemeralDHKeySize=2048
[2022-02-23 07:58:19] [info] Command line argument: 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
[2022-02-23 07:58:19] [info] Command line argument: 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
[2022-02-23 07:58:19] [info] Command line argument: 
-Dignore.endorsed.dirs=
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.base=/var/lib/tomcat9
[2022-02-23 07:58:19] [info] Command line argument: 
-Dcatalina.home=/usr/share/tomcat9

[2022-02-23 07:58:19] [info] Command line argument: -Djava.io.tmpdir=/tmp
[2022-02-23 07:58:19] [info] The Apache Tomcat Native library which 
allows using OpenSSL was not found on the java.library.path: 
[/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib]
[2022-02-23 07:58:19] [crit] Failed to initialize component 
[Connector[org.apache.coyote.http11.Http11AprProtocol-443]]
[2022-02-23 07:58:19] [crit] org.apache.catalina.LifecycleException: 
The configured protocol [org.apache.coyote.http11.Http11AprProtocol] 
requires the APR/native library which is not available


Any idea why the native library, which was available before the 
upgrade, is not anymore available?


How can I diagnose the problem further?

Thanks,



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

Re: Tomcat won't use TLSv1.2

[i...@flyingfischer.ch]

Am 06.03.20 um 15:41 schrieb Christopher Schultz:
> Markus,
>
> On 3/5/20 13:44, i...@flyingfischer.ch wrote:
> > Try SSLProtocol="TLSv1.2" (mind the case) instead of
> > sslProtocol="-all +TLSv1.2".
>
> This is correct when using either OpenSSL or JSSE. "sslProtocol" will
> only work for JSSE configuration, and basically only allows a single
> value: "TLS".
>
> It's better to use  where it's always just "protocols".
>
> > Had this issue too. The connector parameters for SSL are a huge
> > mess and have been changed constantly.
>
> Really? Can you give an example? Other than the change from
>  to , everything has been pretty stable for
> ... decades.
>
> -chris
>
Well, yes. If I remember correctly this was:

    
    
    

Server is also built with TC native. Always using latest stable version
of TC 8.5. OpenJDK 64-Bit Server VM Zulu13.29+9-CA (build 13.0.2+6-MTS,
mixed mode, sharing).

Chrome could not cope with HTTP2 with this configuration. So I switched
back to HTTP1.1

    
    

TLSv1.2 only started to work after correcting sslProtocol to SSLProtocol.

Best
Markus



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

Re: Tomcat won't use TLSv1.2

[i...@flyingfischer.ch]

Am 05.03.20 um 23:10 schrieb rugman66 .:
> On Thu, Mar 5, 2020 at 10:44 AM i...@flyingfischer.ch
>  wrote:
>> Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all
>> +TLSv1.2".
>>
>> Had this issue too. The connector parameters for SSL are a huge mess and
>> have been changed constantly.
>>
>> Best
>> Markus
>>
>> Am 05.03.20 um 19:30 schrieb rugman66 .:
>>> Hello,
>>>
>>>
>>>
>>> I have both Apache and Tomcat running on the same RHEL. I have successfully
>>> configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use
>>> TLSv1.2. Tomcat for some reason
>>>
>>> will only use TLV 1.0, and that is no good. No matter what parameter I set
>>> in the server.xml sslProtocol directive it won’t change. Seems like it’s
>>> getting that directive somewhere else but I can't locate.
>>>
>>>
>>>
>>> >>
>>>  port="8443"
>>>
>>>  scheme="https"
>>>
>>>  secure="true"
>>>
>>>  protocol="org.apache.coyote.http11.Http11AprProtocol"
>>>
>>>  SSLEnabled="true"
>>>
>>>  SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer"
>>>
>>>
>>> SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer"
>>>
>>>
>>> SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key"
>>>
>>>  SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW"
>>>
>>>  SSLHonorCipherOrder="true"
>>>
>>>  maxThreads="150"
>>>
>>>  clientAuth="false"
>>>
>>>  sslProtocol="-all +TLSv1.2"
>>>
>>> />
>>>
>>>
>>>
>>> OpenSSL 1.0.2d
>>>
>>> Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this
>>> time)
>>>
>>>
>>> Thank you for any insight.
>>>
>>> -John
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> Sorry, that last reply sent before I was done for some reason.
>
> Thanks Markus,
>
> One final issue. One version of the URL is still using TLS 1.0, and I
> need to disable or force it to TLS v1.2 and can't find where to do
> that.
>
> https://server.domain.com  (TLSv 1.2)
> https://server.domain.com/foo (Apache proxy TLSv1.2
> https://server.domain.com:8443 (TLS 1.0)
>
> Thanks
> -John
>

These three URLs do use two different connectors: on Port 443 and on
Port 8443.

Make sure you have configured both connectors accordingly.

Best
Markus




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

Re: Tomcat won't use TLSv1.2

[i...@flyingfischer.ch]

Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all
+TLSv1.2".

Had this issue too. The connector parameters for SSL are a huge mess and
have been changed constantly.

Best
Markus

Am 05.03.20 um 19:30 schrieb rugman66 .:
> Hello,
>
>
>
> I have both Apache and Tomcat running on the same RHEL. I have successfully
> configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use
> TLSv1.2. Tomcat for some reason
>
> will only use TLV 1.0, and that is no good. No matter what parameter I set
> in the server.xml sslProtocol directive it won’t change. Seems like it’s
> getting that directive somewhere else but I can't locate.
>
>
>
> 
>  port="8443"
>
>  scheme="https"
>
>  secure="true"
>
>  protocol="org.apache.coyote.http11.Http11AprProtocol"
>
>  SSLEnabled="true"
>
>  SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer"
>
>
> SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer"
>
>
> SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key"
>
>  SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW"
>
>  SSLHonorCipherOrder="true"
>
>  maxThreads="150"
>
>  clientAuth="false"
>
>  sslProtocol="-all +TLSv1.2"
>
> />
>
>
>
> OpenSSL 1.0.2d
>
> Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this
> time)
>
>
> Thank you for any insight.
>
> -John
>


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

Re: secureRandom... using [SHA1PRNG] ..took (up to) 20 minutes

[i...@flyingfischer.ch]

apt-get install haveged
update-rc.d haveged defaults

Increases entropy pool and there for reduces start up time for Tomcat.

Markus


Am 30.12.19 um 11:22 schrieb Rainer Jung:
> It depends a bit on the major Java version you are using, but have a
> look at this page:
>
> https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp#HowToFasterStartUp-EntropySource
>
>
> Regards,
>
> Rainer
>
> Am 30.12.2019 um 05:01 schrieb Vince Stewart:
>> I started recently using my my java app with embedded Tomcat / 8.0.28
>> on a
>> debian VPS (DigitalOcean).
>>
>> Unfortunately, it can take up to 20 minutes to launch into action
>> from the
>> time you start execution. The issue relates to "Creation of SecureRandom
>> instance ... using SHA1PRNG".  Slowness has been described and
>> explained in
>> Stackoverflow.
>>
>> My tomcat has otherwise been so reliable that I have had no
>> motivation to
>> keep it upgraded.  Can anyone advise if some change will apply if I
>> upgrade
>> to the latest version 8.
>>
>> Otherwise, is there a configuration change I could employ.
>>
>> Many thanks,
>
> -
> 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 8.5.48: java.lang.StringIndexOutOfBoundsException

[i...@flyingfischer.ch]

Thanks for confirming and fixing.

Markus

Am 24.11.19 um 12:34 schrieb Mark Thomas:
> Thanks for providing the additional information.
>
> Confirmed. This is a regression in the fix for:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=63815
>
> Yon can work-around this by reverting the addition of " in daemon.sh
> made in this commit:
> https://markmail.org/message/ouaatfznmjbrva23
>
> I'll get this fixed for the next release. The November release was
> fairly late. The December one should (hopefully) be nearer the beginning
> of the month.
>
> Also...
>
> On 24/11/2019 08:20, i...@flyingfischer.ch wrote:
>
>>>> built with
>>>>
>>>> commons-daemon-native
>>>> tomcat-native (./configure --with-apr=/usr/bin/apr-1-config
>>>> --with-java-home=$JAVA_HOME --with-ssl=yes
>>>> --prefix=/usr/share/tomcat8/$newVersion)
> Commons daemon doesn't depend on APR, nor on OpenSSL. That looks like a
> configure for Tomcat Native rather than Commons Daemon.
>
> 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 8.5.48: java.lang.StringIndexOutOfBoundsException

[i...@flyingfischer.ch]

Starting Tomcat with "service tomcat start | stop | restart" pointing to:

#!/bin/bash

### BEGIN INIT INFO
# Provides:    tomcat
# Required-Start:  $network
# Required-Stop:   $network
# Default-Start:   2 3 4 5
# Default-Stop:    0 1 6
# Short-Description: Start/Stop Tomcat server
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/share/tomcat/bin/daemon.sh

case $1 in
    start)
    $DAEMON --java-home /usr/lib/jvm/zulu-13-amd64/
--tomcat-user restrictedtomcatuser start
    ;;
    stop)
    $DAEMON --java-home /usr/lib/jvm/zulu-13-amd64/
--tomcat-user restrictedtomcatuser stop
    ;;
    restart)
    $0 stop
    $0 start
    ;;
    *)
    echo "Usage: $0 {start|stop|restart}"
esac

Markus


Am 23.11.19 um 20:44 schrieb Mark Thomas:
> On 23/11/2019 15:38, i...@flyingfischer.ch wrote:
>> openjdk version "13.0.1" 2019-10-15
>> OpenJDK Runtime Environment Zulu13.28+11-CA (build 13.0.1+10-MTS)
>> OpenJDK 64-Bit Server VM Zulu13.28+11-CA (build 13.0.1+10-MTS, mixed
>> mode, sharing)
> And how are you calling jsvc?
>
> From the stack trace it looks like an empty string is being passed as
> the class name.
>
> I wonder if this is related:
> https://markmail.org/message/ouaatfznmjbrva23
>
> Mark
>
>
>> Linux
>>
>> built with
>>
>> commons-daemon-native
>> tomcat-native (./configure --with-apr=/usr/bin/apr-1-config
>> --with-java-home=$JAVA_HOME --with-ssl=yes
>> --prefix=/usr/share/tomcat8/$newVersion)
>>
>> Markus
>>
>>
>> Am 23.11.19 um 11:37 schrieb Mark Thomas:
>>> On 23/11/2019 09:43, i...@flyingfischer.ch wrote:
>>>> After updating to Tomcat 8.5.49 starting TC on daemon fails with:
>>>>
>>>> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>>>> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48)
>>>> at java.base/java.lang.String.charAt(String.java:709)
>>>> at
>>>> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:136)
>>>> Cannot load daemon
>>>> Service exit with a return value of 3
>>>>
>>>> Did needto roll back to 8.5.47 which runs fine.
>>> Care to provide a few more details?
>>>
>>> Java version?
>>>
>>> Operating system?
>>>
>>> Steps to reproduce from a clean 8.5.49 install?
>>>
>>> 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

Re: Tomcat 8.5.48: java.lang.StringIndexOutOfBoundsException

[i...@flyingfischer.ch]

openjdk version "13.0.1" 2019-10-15
OpenJDK Runtime Environment Zulu13.28+11-CA (build 13.0.1+10-MTS)
OpenJDK 64-Bit Server VM Zulu13.28+11-CA (build 13.0.1+10-MTS, mixed
mode, sharing)

Linux

built with

commons-daemon-native
tomcat-native (./configure --with-apr=/usr/bin/apr-1-config
--with-java-home=$JAVA_HOME --with-ssl=yes
--prefix=/usr/share/tomcat8/$newVersion)

Markus


Am 23.11.19 um 11:37 schrieb Mark Thomas:
> On 23/11/2019 09:43, i...@flyingfischer.ch wrote:
>> After updating to Tomcat 8.5.49 starting TC on daemon fails with:
>>
>> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48)
>> at java.base/java.lang.String.charAt(String.java:709)
>> at
>> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:136)
>> Cannot load daemon
>> Service exit with a return value of 3
>>
>> Did needto roll back to 8.5.47 which runs fine.
> Care to provide a few more details?
>
> Java version?
>
> Operating system?
>
> Steps to reproduce from a clean 8.5.49 install?
>
> 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

Tomcat 8.5.48: java.lang.StringIndexOutOfBoundsException

[i...@flyingfischer.ch]

After updating to Tomcat 8.5.49 starting TC on daemon fails with:

java.lang.StringIndexOutOfBoundsException: String index out of range: 0
at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:48)
at java.base/java.lang.String.charAt(String.java:709)
at
org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:136)
Cannot load daemon
Service exit with a return value of 3

Did needto roll back to 8.5.47 which runs fine.

Best
Markus

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

Re: Jakarta EE 9

[i...@flyingfischer.ch]

Am 28.10.19 um 15:39 schrieb Mark Thomas
>> If this is going to be disruptive and we cannot maintain compat, why
>> not 
>> go the extra step and explicitly move Tomcat code to
>> org.apache.tomcat.* 
>> for Tomcat 10? Git renames will work flawlessly for backports.
> It will break things for users that code against those APIs. It is a small 
> number but some do.
>
> Mark
Do you have any evidence based number on this matter? May be in turns
oout that this "small number" isn't as small as assumed...

Markus

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

Re: Bug with Tomcat-8.5 and Apache Commons FileUpload

[i...@flyingfischer.ch]

Thanks! Setting overheadDataThreshold="0" does fix the issue.

Without overheadDataThreshold the issue is very inconsistent:

Firefox 69.0.1 (64-Bit) on LNX and on other OS does result in the
described error below.

Very strange: Chrome on LNX mostly works, which means I got
intermittently once got "connection closed" with Chrome. On the second
retry the upload worked.
Even stranger: after a successful upload by Chrome it even works with FF
with the same file.

Markus

Am 30.09.19 um 20:49 schrieb Mark Thomas:
> That sounds like the client has tripped the overhead threshold protection.
>
> As a short term fix you probably want to see a lower value for:
> overheadDataThreshold
>
> see: http://tomcat.apache.org/tomcat-8.5-doc/config/http2.html
>
> possibly as low as zero.
>
> Longer term you should ideally look into why the client is sending
> small, non-final DATA frames since that as inefficient and has been
> identified as a potential DoS vector in some servers (not Tomcat but we
> block it as abusive behaviour anyway).
>
> Depending on what the client is doing, you may need to adjust the other
> over head thresholds as well. If you have a reproducible test case,
> enabling debug for http2 in logging.properties should shed some light on
> exactly what is going on.
>
> Mark
>
>
> On 30/09/2019 17:48, i...@flyingfischer.ch wrote:
>> I stumbled over a new problem which very likely appeared after
>> apache-tomcat-8.5.43 and between apache-tomcat-8.5.46
>>
>> Using Apache Commons FileUpload gives for some kind of PDF files:
>>
>> [https-openssl-apr-443-exec-15]
>> org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest
>> Failed to parse multipart request
>>
>> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
>> Processing of multipart/form-data request failed. java.io.IOException:
>> The socket associated with this connection has been closed.
>>
>> This only happens when using HTTP/2. Upload works when downgrading
>> tomcat to HTTP/1.
>>
>> There has been posted a similiar error report on Stackoverflow, which
>> indicates that the sizes of the files may be the reason:
>>
>> https://stackoverflow.com/questions/58118776/apache-commons-fileupload-problems-uploading-files-greater-than-100kb-using-htt
>>
>> Thanks for considering
>> Markus
>>
>>
>>
>> -
>> 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

Bug with Tomcat-8.5 and Apache Commons FileUpload

[i...@flyingfischer.ch]

I stumbled over a new problem which very likely appeared after
apache-tomcat-8.5.43 and between apache-tomcat-8.5.46

Using Apache Commons FileUpload gives for some kind of PDF files:

[https-openssl-apr-443-exec-15]
org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest
Failed to parse multipart request

org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. java.io.IOException:
The socket associated with this connection has been closed.

This only happens when using HTTP/2. Upload works when downgrading
tomcat to HTTP/1.

There has been posted a similiar error report on Stackoverflow, which
indicates that the sizes of the files may be the reason:

https://stackoverflow.com/questions/58118776/apache-commons-fileupload-problems-uploading-files-greater-than-100kb-using-htt

Thanks for considering
Markus



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

HttpClient 5.0 / Apache Tomcat

[i...@flyingfischer.ch]

In case anybody with advanced Docker skills is interested to help
improve compatibility tests between HttpClient 5.0 and Apache Tomcat:

http://mail-archives.apache.org/mod_mbox/hc-dev/201909.mbox/%3C0d30be42ab3743b48fd73122a4421d11d301761b.camel%40apache.org%3E

Best
Markus

-
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.24 available

[i...@flyingfischer.ch]

Am 19.08.19 um 19:43 schrieb i...@flyingfischer.ch:
> Am 19.08.19 um 10:00 schrieb Mark Thomas:
>> The Apache Tomcat team announces the immediate availability of Apache
>> Tomcat 9.0.24.
>>
>> 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.24 is a bugfix and feature release. The notable
>> changes compared to 9.0.22 include:
>>
>> - Expand Graal native image support to include JNDI, JSPs and JULI
>>
>> - Expand the HTTP/2 excessive overhead protection to cover various forms
>>   of abusive client behaviour and close the connection if any such
>>   behaviour is detected.
>>
>> - Security improvements to the Windows installer including a change in
>>   the default user from Local System to Local Service.
>>
>> Please refer to the change log for the complete list of changes:
>> http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
>>
>>
>> Downloads:
>> http://tomcat.apache.org/download-90.cgi
>>
>> Migration guides from Apache Tomcat 7.x and 8.x:
>> http://tomcat.apache.org/migration.html
>>
>> Enjoy!
>>
>> - The Apache Tomcat team
>>
> 
> 
> Released version is 9.0.24.
> 
> Unpacking Tomcat native in /bin gives a folder named:
> 
> tomcat-native-1.2.23-src
> 
> while this should be
> 
> tomcat-native-1.2.24-src
> 
> This may cause problems in automated update scripts.
> 
> Best Markus
> 

Another issue:

bin/commons-daemon-1.2.0-native-src/unix

does not contain the necessary script to run ./configure under linux

Present is only configure.in

Markus


-
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.24 available

[i...@flyingfischer.ch]

Am 19.08.19 um 10:00 schrieb Mark Thomas:
> The Apache Tomcat team announces the immediate availability of Apache
> Tomcat 9.0.24.
> 
> 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.24 is a bugfix and feature release. The notable
> changes compared to 9.0.22 include:
> 
> - Expand Graal native image support to include JNDI, JSPs and JULI
> 
> - Expand the HTTP/2 excessive overhead protection to cover various forms
>   of abusive client behaviour and close the connection if any such
>   behaviour is detected.
> 
> - Security improvements to the Windows installer including a change in
>   the default user from Local System to Local Service.
> 
> Please refer to the change log for the complete list of changes:
> http://tomcat.apache.org/tomcat-9.0-doc/changelog.html
> 
> 
> Downloads:
> http://tomcat.apache.org/download-90.cgi
> 
> Migration guides from Apache Tomcat 7.x and 8.x:
> http://tomcat.apache.org/migration.html
> 
> Enjoy!
> 
> - The Apache Tomcat team
> 


Released version is 9.0.24.

Unpacking Tomcat native in /bin gives a folder named:

tomcat-native-1.2.23-src

while this should be

tomcat-native-1.2.24-src

This may cause problems in automated update scripts.

Best Markus

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

Re: Massive Startup Time after Server Reboot

[i...@flyingfischer.ch]

Sorry, you seem to be lost on a Windows Server...

...haveged won't help you in this situation.

Markus


Am 18.05.19 um 23:39 schrieb i...@flyingfischer.ch:
> Try
>
> apt-get install haveged
> update-rc.d haveged defaults
>
> This increases the system entropy for random generation and reduces boot
> time for Tomcat considerably.
>
> Markus
>
>
> Am 18.05.19 um 22:18 schrieb Rainer Jung:
>> Most likely it hangs waiting for enough entropy for random number
>> generator seeding.
>>
>> Try whether the problem goes away if you add
>>
>>   -Djava.security.egd=file:/dev/urandom
>>
>> to you process flags. If you are using older Java than Java 8 (not
>> possible for Tomcat 9 but just in case you also have older software
>> stacks running), then it would be
>>
>>   -Djava.security.egd=file:/dev/./urandom
>>
>> The cryptic /./ is not a typo, you would need it for Java before Java 8.
>>
>> If this doesn't help, then you should try capturing a few stack dumps
>> (thread dumps) during the long startup time. People here can help
>> interpret them.
>>
>> Regards,
>>
>> Rainer
>>
>> Am 18.05.2019 um 21:55 schrieb Jerry Malcolm:
>>> This is a weird one.  It started a few months ago.   I have TC 9
>>> running on Windows Server 16.  After I reboot the entire server,
>>> Tomcat takes forever on startup.  It normally starts in about 30
>>> seconds.  But after a server reboot it takes up to 15 minutes...
>>> chugging along at a snail's pace starting up all of the apps on all
>>> of the virtual hosts.  It always finally gets there with everything
>>> successfully running.  Other servers on the same box (Apache, JAMES,
>>> ISC BIND, MySQL) don't have any problem starting up.  CPU, Disk,
>>> Memory, etc. usages are barely showing on the performance graphs. 
>>> There's nothing in the Catalina log or system.err other than showing
>>> a couple of minute gap in the time stamp between each app as it
>>> starts up.  If I need to reboot again later, it boots again in about
>>> 30 sec as expected.
>>>
>>> First question... any ideas off the top of your head that might be
>>> causing this?
>>>
>>> Second question... is there any other logging I can turn on that
>>> might explain what TC is blocking on?
>>>
>>> Thanks.
>>>
>>> Jerry
>> -
>> 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: Massive Startup Time after Server Reboot

[i...@flyingfischer.ch]

Try

apt-get install haveged
update-rc.d haveged defaults

This increases the system entropy for random generation and reduces boot
time for Tomcat considerably.

Markus


Am 18.05.19 um 22:18 schrieb Rainer Jung:
> Most likely it hangs waiting for enough entropy for random number
> generator seeding.
>
> Try whether the problem goes away if you add
>
>   -Djava.security.egd=file:/dev/urandom
>
> to you process flags. If you are using older Java than Java 8 (not
> possible for Tomcat 9 but just in case you also have older software
> stacks running), then it would be
>
>   -Djava.security.egd=file:/dev/./urandom
>
> The cryptic /./ is not a typo, you would need it for Java before Java 8.
>
> If this doesn't help, then you should try capturing a few stack dumps
> (thread dumps) during the long startup time. People here can help
> interpret them.
>
> Regards,
>
> Rainer
>
> Am 18.05.2019 um 21:55 schrieb Jerry Malcolm:
>> This is a weird one.  It started a few months ago.   I have TC 9
>> running on Windows Server 16.  After I reboot the entire server,
>> Tomcat takes forever on startup.  It normally starts in about 30
>> seconds.  But after a server reboot it takes up to 15 minutes...
>> chugging along at a snail's pace starting up all of the apps on all
>> of the virtual hosts.  It always finally gets there with everything
>> successfully running.  Other servers on the same box (Apache, JAMES,
>> ISC BIND, MySQL) don't have any problem starting up.  CPU, Disk,
>> Memory, etc. usages are barely showing on the performance graphs. 
>> There's nothing in the Catalina log or system.err other than showing
>> a couple of minute gap in the time stamp between each app as it
>> starts up.  If I need to reboot again later, it boots again in about
>> 30 sec as expected.
>>
>> First question... any ideas off the top of your head that might be
>> causing this?
>>
>> Second question... is there any other logging I can turn on that
>> might explain what TC is blocking on?
>>
>> Thanks.
>>
>> Jerry
>
> -
> 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 Nio2+OpenSSL problem (very likely a bug)

[i...@flyingfischer.ch]

Am 18.03.19 um 16:43 schrieb Igor T:
>> Since 9.0.12 and 16 do the same, I wouldn't look at that at all. Something
>> simple like this works in the general case, there must be something
>> specific here. So it's Windows, which some unspecified OpenSSL version.
>>
>> Rémy
> That's not right. After many tests I've found out that 9.0.12 build
> comes with [OpenSSL 1.0.2o  27 Mar 2018], while 9.0.16 comes with
> [OpenSSL 1.1.1a  20 Nov 2018].
> The problem was localized to OpenSSL 1.1.1a on Nio2.
> Also it became clear that establishing of connection takes more time
> with OpenSSL 1.1.1a on Nio.
> So it looks like OpenSSL 1.1.1a build is much less optimized and buggy.
>
> So the question is: how to change OpenSSL version that is shipped with
> the latest tomcat build back to 1.0.2?
> Any feedback appreciated.
>

I did have to reset some installations to Tomcat 8.5.35 to avoid using
TC native latest two versions on Linux. We have seen some bugfixes in
the lastes TC native, which did slightly improve the situation. But TC
still tends to crash on some machines (Linux).

Some of the changes made in native after 8.5.35 are unstable.

Markus

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

Re: Tomcat memory growth while using TLS

[i...@flyingfischer.ch]

Am 11.01.19 um 18:23 schrieb Mark Thomas:
> Found it.
>
> The leak impacted NIO and NIO2 when used with OpenSSL.
>
> The bug is in Tomcat Native. I have a fix that I am currently testing.
> That fix should be in the next Tomcat Native release.
>
> For those interested in the technical details, Tomcat Native allocates
> some Native memory to track various attributes of each connection.
>
> In APR/Native this memory is allocated from a new APR memory pool that
> is associated with the connection. When the connection closes, the pool
> is destroyed and the memory freed. All is good.
>
> In NIO[2]+OpenSSL the per connection memory was allocated from the APR
> memory pool associated with the Connector so the memory was not released
> until the Connector was stopped. The fix is to create a pool per
> connection and use that for the per connection allocations. With a fix
> to do that in place, memory use is now broadly static under extended TLS
> load.
>
> Mark
>

Thanks Mark!

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

Re: Tomcat memory growth while using TLS

[i...@flyingfischer.ch]

Am 09.01.19 um 11:14 schrieb Mark Thomas:
> On 08/01/2019 23:51, Mason Meier wrote:
>> Hello,
>>
>> I'm running Tomcat-8.5 with TLS and I've noticed substantial memory growth
>> with requests over time, to the point that if I run Tomcat in Docker and
>> make constant requests to it, Docker will kill the container due to
>> excessive memory utilization. The problem occurs with standalone Tomcat as
>> well. Over the course of millions of requests, the memory usage of the
>> Tomcat process grows continuously, seemingly without bound.
> I've behaviour like this in the past. From memory there was some caching
> in the TLS implementation at the root of most of it that could be
> controlled with some system properties.
>
> It may be you are seeing the same thing. Or you may have found a memory
> leak. The next step would be to use a profiler to see where the memory
> is being used.
>
>> I've done a fair amount of testing on AWS EC2 instances and some local
>> machines, and here are my observations:
>>   * 'org.apache.tomcat.util.net.openssl.OpenSSLImplementation' seems to
>> increase memory utilization more quickly and consistently than
>> 'org.apache.tomcat.util.net.jsse.JSSEImplementation'. The
>> JSSEImplementation doesn't cause the memory to grow in certain setups.
> Can you share some configs that demonstrate an issue and some that
> don't. That might help narrow down what is going on.
>
> Mark
>

We do also see frequent OOM memories with the latest Tomcat versions.
Free memory shrinks to a critical value. With previous versions this
behaviour was not here. However, we use a limited machine and I need to
investigate further.

Markus

>
> -
> 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: Wrong content-type for CSS files since 8.5.37 / 9.0.14

[i...@flyingfischer.ch]

Am 27.12.18 um 21:34 schrieb Rémy Maucherat:
> On Thu, Dec 27, 2018 at 9:30 PM Mark Thomas  wrote:
>
>> On December 26, 2018 9:49:00 PM UTC, "i...@flyingfischer.ch" <
>> i...@flyingfischer.ch> wrote:
>>> Tomcat versions 8.5.37 and 9.0.14 seem to serve CSS files embedded in a
>>> webapp as
>>>
>>> content-type: text/html;charset=UTF-8
>>>
>>> instead of
>>>
>>> content-type: text/css;charset=UTF-8
>>>
>>> This causes the browser (FF) not to interpret the CSS.
>>>
>>> I suspect the listed change in changelog of 8.5.36: "The default
>>> Servlet
>>> should not override a previously set content-type. (remm)"
>> Sounds likely.
>>
>> Whatever part of the app is setting the incorrect content type (probably a
>> filter) needs to be fixed.
>>
> Yes, I also prefer keeping the new behavior, which was suggested by
> Christopher. Worst case scenario there should be a new init-param.
>
> Rémy
>
I could get it fixed by disabling a filter in the (legacy) app, which
did set a hardcoded content-type to UTF-8.

Markus


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

Wrong content-type for CSS files since 8.5.37 / 9.0.14

[i...@flyingfischer.ch]

Tomcat versions 8.5.37 and 9.0.14 seem to serve CSS files embedded in a
webapp as

content-type: text/html;charset=UTF-8

instead of

content-type: text/css;charset=UTF-8

This causes the browser (FF) not to interpret the CSS.

I suspect the listed change in changelog of 8.5.36: "The default Servlet
should not override a previously set content-type. (remm)"

Markus

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

Re: mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping

[i...@flyingfischer.ch]

> Hi all,
> 
> I have problems to pass (REST-) URLs containing escaped slashes ('%2F') in 
> path elements using the  Apache httpd  and  mod_jk  to the application server 
> (in fact not Tomcat, but Wildfy. But this is of no matter, here).
> 
> This kind of URL may be accepted by the httpd using the option 
> 'AllowEncodedSlashes=NoDecode'. But then, while using the mode 
> 'ForwardURIProxy' for mod_jk , they are re-encoded in a bad way: As '%252F', 
> because the percent sign itself is escaped by accident. The result is a 
> syntactically bad URL which is rejected by the application server.
> 
> I already filed this last week as  
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 . Please, may take some 
> maintainer a look at this?
> 
> with greetings
> 
> Guido
> 

You may want to create setenv.sh in CATALINA_HOME/bin with the following
option:

export
JAVA_OPTS="-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true"


Markus

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

relaxedPathChars / relaxedQueryChars XML

[i...@flyingfischer.ch]

Thanks for the two new configurable options relaxedPathChars and
relaxedQueryChars.

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

However, since these two elements will be nested in server.xml, adding

"<>"

will result in an invalid XML and a failing reboot of tomcat.

The instructions quote: "Any other characters present in the value will
be ignored".

https://tomcat.apache.org/tomcat-8.5-doc/config/http.html

So, I am not sure if adding  and  actually do work?

Markus

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

Re: Am I reinventing the wheel to get letsencrypt certs for Tomcat

[i...@flyingfischer.ch]

Am 27.10.2017 um 15:29 schrieb André Warnier (tomcat):
> On 27.10.2017 15:05, Don Flinn wrote:
>> Hi Andre,
>>
>> I have looked and it may be my ignorance but I didn't find any that
>> seemed
>> to fit.  I'll look more closely at the available letsencrypt clients.
>
> It is certainly more my own ignorance, rather than yours. I was only
> pointing out the obvious, since a fair number of people who post
> questions here seem to not bother doing their own homework first, and
> neglect obvious sources of information such as the WWW or the Tomcat FAQ.
>
> Your proposal solution below sounds very nice, and would certainly be
> of immense help to SSL/HTTPS dummies such as myself.
> I'm out of my depth already, but on this forum, Christopher may be the
> person most able to provide thoughtful and competent comments
> regarding such matters.
> I guess he'll be in shortly, being on the same oceanic side as you are
> (or seem to be; one never really knows these days).

Let's Encrypt will roll out an ACME module for Apache httpd called mod_md:

https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html

It would be most interesting to have a similar functionality directly
built into Tomcat, taking care of LE certs and their wildcard certs
coming next year.

Best regards
Markus

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

Re: TLD scanning performance question

[i...@flyingfischer.ch]

>
> Yes, it's the SecureRandom initialization that is killing you. Being a
> virtual server, it likely has no direct source of true randomness so
> it needs to pull from whatever the hypervisor is willing to provide.
>
> You'll need to ask your virtualization vendor for how to get access to
> more entropy, or switch to a less-secure random source (e.g.
> /dev/urandom on *NIX-like systems).
>
Install haveged and your boot up problems will be gone.

Markus


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

Re: URL-encoding and "#"

[i...@flyingfischer.ch]

Am 13.10.2017 um 12:48 schrieb Alex O'Ree:
> Well that explains a lot. Similar issue for me. With url encoding,  tomcat
> is dropping back slash and the plus symbol.

While I think it is perfectly eligible to strive for a most perfect
alignement with standards and specs, I think Tomcat should allow a
reasonnable set of characters to be optionally allowed (as they already
are in Tomcat up to 8.5).

I am aware that these options may be a security issue and that the
documentation should state that clearly. However it is not always
possible to correct the environment to be "standard" compatible and the
educational approach by not allowing these options is understandable but
may be not appropriate in many situations.

Best regards
Markus

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

Re: URL-encoding and "#"

[i...@flyingfischer.ch]

Am 13.10.2017 um 09:01 schrieb Mark Thomas:
> From memory, # isn't one of the allowed exceptions.
>
> The full list of invalid characters in the request line that Tomcat
> started to check for is:
> ' ', '\"', '#', '<', '>', '\\', '^', '`', '{', '|', '}'
>
> The allowed exceptions are (currently) '{', '|', '}'
>
> Mark
By the way:

While fully agreeing, that the '#' character should not be sent by a
client to the server, it still would be desirable to have those three by
optional configuration allowed characters, also be made a configurable
exception in Tomcat 9.

As fas as I know, this option has been allowed up to and including
Tomcat 8.5 only.

While it is a good thing to save the world, real world scenarios may differ.

Thanks for considering.

Markus

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

Re: Apache Struts

[i...@flyingfischer.ch]

Am 14.09.2017 um 18:38 schrieb Small, Wayne H:
> All,
>   A question for the forum:  Does TomCat 8.5.13 use Apache Struts or the Rest 
> plugin?
>
>
> Wayne Small
> Software Engineer Sr.
> Lockheed Martin
> Clearwater Manufacturing Facility
> 3655 Tampa Road
> Oldsmar, FL. 34677
> 813-854-7305 - office
> 727-455-0192 - mobile
>
> Vacation
> 05/27/2018-06/10/2018
>
> Opportunity is missed by most people because it is dressed in overalls and 
> looks like work. - Thomas Edison
>
>

No, Tomcat does not.

Your web appliactions deployed in Tomcat may or may not.

Try to search the archives:

https://marc.info/?l=tomcat-user=2=1=struts=b

Markus

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

Re: Apache Struts 2 Vulnerability in Tomcat 7.x

[i...@flyingfischer.ch]

Am 08.09.2017 um 10:59 schrieb Billy Aung Myint:
> Hi Everyone,
>
> May I know if Tomcat 7.x version is affected by the Apache Struts 2 
> vulnerability?
> I mean does Tomcat uses any of the Struts' libraries or such in any part of 
> the Tomcat?
>
> Thanks!
>
Tomcat is affected by Tomcat vulnerabilities, Struts is affected by
Struts vulnerabilities.

If you deploy old and not uptodate Struts libraries in Tomcat, then you
will be exposed to the corresponding exploits. In this case, as always
and independent of the nature of the component: upgrade to the latest
available version and or use other measure to block attacking requests.

Markus

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

Re: Access to source IP address during authentication and authorization

[i...@flyingfischer.ch]

Am 08.08.2017 um 14:05 schrieb Christopher Schultz:
> All,
>
> In spite of my (somewhat) recent work on the CredentialHandlers, I
> haven't been using Tomcat's container-provider authentication and
> authorization for over a decade. This is because I need access to the
> user's source IP address for auditing where users "are" when they
> login to my applications.
>
> Is there any opportunity to obtain the user's IP address during login?
> IIRC, the JASPIC scheme does allow this kind of information, but I'm
> not sure if Tomcat actually supplies it. JASPIC is a rather
> complicated solution when I am in fact authenticating against a simple
> relational database.
>
> What might be other ways to obtain the user's IP address during
> authentication?
>
> Thanks,
> -chris
>
> PS I don't use Spring, to "just use Spring security like everyone
> else" isn't a great solution for me.

If you run Tomcat only you may use request.getRemoteAddr() in the logic
and build IP based access management around this.

If you run Apache in front of Tomcat you may need to fiddle with
X-Forwarded-For header.

Markus




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

Re: java

[i...@flyingfischer.ch]

Am 18.07.2016 um 17:14 schrieb Sanka, Ambica:

Steffen,
Is it also possible to test your stuff with jdk1.8.0_51 so that we will know 
something must be wrong with security in jdk1.8.0_51?
Appreciate your help
Ambica.



You may want to follow the changes in

http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html

There have been several changes regarding the acceptance of 
certificates. You may change this behaviour in


/usr/lib/jvm/java-8-oracle/jre/lib/security/java.security

Any changes in this file will be overriden by the next update.

Markus

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

SSL inconsistency

[i...@flyingfischer.ch]

While testing locally the new 8.5 branch, I did experience some 
inconsistency with self-sigend SSL certs. I did manage to resolve them 
by installing Tomcat-Native library / APR, but maybe it is still worth 
reporting in regard of the different behaviour for the same cert, 
between Tomcat versions and configuartions.


I didn't want to file a bug, since this very likely is a configuration 
and/or self-signed cert problem.


Thanks for considering.

Markus

Tomcat 8, works fine.
Tomcat 8.5  error => Alias name tomcat does not identify a key entry



---

Tomcat 8.5, same cert, starts fine but throws on first SSL invocation:

java.lang.IllegalArgumentException: Invalid character found in method 
name. HTTP method names must be tokens




---

Tomcat 8.5, new cert
Tomcat-Native / APR disabled

Failed to initialize end point associated with ProtocolHandler 
["https-jsse-nio-8443"]

java.security.KeyStoreException: Cannot store non-PrivateKeys

Same cert works with Tomcat-Native / APR enabled

protocol="org.apache.coyote.http11.Http11NioProtocol"
   maxThreads="150" secure="true" scheme="https" 
SSLEnabled="true" defaultSSLHostConfigName="localhost">






Also works with protocol="org.apache.coyote.http11.Http11AprProtocol" 
with Tomcat-Native / APR enabled



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