Re: Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Martin Grigorov]

Hi Richard,

On Thu, Mar 5, 2020 at 4:42 AM Richard Huntrods 
wrote:

>
> On 3/4/2020 6:28 AM, Martin Grigorov wrote:
> > On Wed, Mar 4, 2020 at 4:02 PM Johan Compagner 
> > wrote:
> >
> >>>
>  Or for now generate 2 build artifacts? (as long as it is really just
> >> the
>  package rename)
> 
> >>> Hm, no. I just tested locally Tomcat 10.0.1 with Apache Wicket (9.x,
> >>> master). Nothing more.
> >>> Tomcat 10.0.x is not production ready so it is too early to do anything
> >>> about Jakarta APIs in Wicket.
> >>> First we need to release Wicket 9.0.0 (with Javax APIs) and then we can
> >>> start thinking about Jakarta APIs.
> >>>
> >>>
> >> yes exactly, so many frameworks are going to do that (wait)
> >> So not release any artifacts that use the new jakarta api's
> >> So that means that for many people they can't start test or use Tomcat
> 10..
> >> Because who is using plain servlet api only?
> >> Any 3rd part dependency is your code  that uses some javax.servlet
> package
> >> needs to make a special release..
> >> This will take ages, not to mention will only be really done for the
> latest
> >> releases of those packages (like Wicket 9)
> >>
> > There is no official release of Jakarta EE 9 yet!
> > I didn't even bother to replace javax.servlet:servlet-api Maven
> dependency
> > with the Jakarta one in Wicket.
> > I just used https://github.com/apache/tomcat-jakartaee-migration to
> migrate
> > (already built) wicket-examples.war and it worked fine!
> > Later I tried to do the same with a Spring Boot based application but the
> > migration tool faced some problems with the nested archives in Boot's
> > special packaging.
> >
> > Tomcat 10.0.x is for early adopters to test it and report issues. But as
> > Chris suggested we should make this more clear in the docs!
> > I've committed some improvements. If anyone have more ideas for
> improvement
> > I'll be happy to apply them! :-)
>
> Thank you for that Martin. I installed 10.0.x today, and as expected it
> broke because all my servlets are based on javax. I grabbed a copy of
> the migration tool. Sadly (for me) it required Maven to build, but after
> some hesitency, I grabbed Maven and installed that (it was really easy).
>

Thank you for the feedback!
I've added Maven Wrapper script to the project so that it is easier for
non-Maven users like you to build the migration tool without much
hesitency! ;-)
https://github.com/apache/tomcat-jakartaee-migration/commit/198e510a67cec569e91cc2cc87e4f4adb181f753

Martin


>
> With Maven installed and working, I built the migration tool. Again,
> easy. With the tool built I simply converted both of my application's
> war files, copied them over the originals in webapps, started TC 10 and
> everything worked!
>
> So I guess I'm "ready" for TC10 now. :-)
>
> -R
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
> --
> This communication is intended for the use of the recipient to whom it is
> addressed, and may contain confidential, personal, and or privileged
> information. Please contact us immediately if you are not the intended
> recipient of this communication, and do not copy, distribute, or take
> action relying on it. Any communications received in error, or subsequent
> reply, should be deleted or destroyed.
> ---
>

Aw: Re: Fix for CVE-2020-1938

[Jürgen Göres]

>
>Ghostcat is the name of a malware strain that has been around since at
>least October last year. When referencing vulnerabilities it is best to
>stick to the CVE reference since they should be unique (and if something
>goes wrong and they aren't there are procedures to get them re-issued so
>they are).
>
>> we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the AJP 
>> protocol since we use Apache HTTPD as reverse proxy and found it to be 
>> mostly hazzle-free over the last few years, so we would like to continue 
>> using it.
>> Since the HTTPD and the Tomcats are in general not on the same nodes, the 
>> AJP connector has to listen on all interfaces.
>> My first question is: what value do I need to set in the "address" attribute 
>> to indicate that I want the connector to listen on ALL interfaces (for IPv4 
>> AND IPv6)? Maybe that should be documented. :-)
>
>It will vary by system. Some systems can't listen on both IPv4 and IPv6
>with a single socker. Usually either "::" or "0.0.0.0" will have the
>desired result.

That is a bit of a problem for us. In the environments we support (Win and 
Linux), from my observation the connectors would successfully bind to both IPv4 
and IPv6 addresses. Since we have customers that use either IPv4, IPv6, or both 
and often have multiple interfaces on their machines, we cannot know which 
address/interface (or even which IP version) to bind to. And up to now, we 
didn't have to worry about it.
Now our installation routine would somehow need to find out whether it should 
put a "::" or a "0.0.0.0" in the "address" attribute. What was "zero conf" for 
us so far now suddently becomes a new source for problems (=customer calls).
Is there no way to optionally configure the old binding behaviour for the AJP 
connector?


>> So the question is: is the root cause actually fixed?
>
>Yes.

Great, thx. :-)


>The very nature of the AJP protocol is such that clients have to be trusted.
>Tomcat trusts the "real" client IP address provided. That could be used
>for access control.
>Tomcat may be configured to trust the authenticated user name provided.
>That almost certainly will then be used for access control.

So far, we had instructions for our customers to not expose the AJP ports (or 
any other internal ports of other components in our stack). However, I am 
pretty sure that there are installations out there where these ports are 
exposed (hopefully only on the intranet).
In any case, we will update to the latest Tomcat version (but need to find a 
way to solve the "to which interface should we bind" problem without too much 
hazzle for customers), and in addition will also try to use the "secret" 
approach to secure access to the AJP connectors, so that even those customers 
that ignored the security guidelines will not be affected by other possible 
attacks over the AJP protocol.

>
>> If it is, what is the recommended mitigation? We consider using the "secret" 
>> feature (the filtering by request attributes is infeasible for us), but that 
>> would be a bit of effort and we are in a hurry.
>
>It would be unusual for an application to be using request attributes
>directly. These have to be explicitly set in the reverse proxy and are
>normally used for the reverse proxy to pass information to Tomcat about
>the client etc.

I was under the naive assumptions that "request attributes" meant "HTTP request 
attributes". ;-)
If I understand you right here we are talking about attributes used in the AJP 
protocol to convey info between reverse proxy and Tomcat.
Like info about the true client IP address (i.e., an AJP equivalent to HTTP's 
X-Forwarded-For header).


>- setting up a dedicated subnet for reverse proxy to Tomcat
>communication;
>- configuring a firewall on the Tomcat box to only accept connections
>to the AJP port from specific hosts

That is what we advise our customers to do.

>For any network configuration you can configure a shared secret for the
>reverse proxy workers and the AJP connector.

And since this is closest to "zero config" we can get, this is what we will do 
on perspective.

Regards

JG


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

Aw: Re: Fix for the Ghostcat vulnerability

[Jürgen Göres]

Hi,
 
>> If it is, what is the recommended mitigation? We consider using the
>> "secret" feature (the filtering by request attributes is infeasible
>> for us), but that would be a bit of effort and we are in a hurry.
>>
>
>We're in the same position as you. External web servers talking to
>Tomcat servers on other boxes via AJP.
>
>We've looked at a few options, none of which seemed great:
>
>* The current stable version of Apache doesn't support the 'secret'
>attribute for AJP connectors in mod_proxy.

we will use the "secret" approach. Since we use mod_jk which supports it, this 
will offer the least trouble when deploying in customer environments.
We will generate a random secret for each tomcat instance. Since our apps 
already register in our service registry,we can just add the secret there. Our 
Apache HTTPD resp. a little tooling we wrote for it that generates the Apache 
config from information in the registry and can pick up the secret from there 
as well.

Regards

JG



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

Re: Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Richard Huntrods]

On 3/4/2020 6:28 AM, Martin Grigorov wrote:

On Wed, Mar 4, 2020 at 4:02 PM Johan Compagner 
wrote:




Or for now generate 2 build artifacts? (as long as it is really just

the

package rename)


Hm, no. I just tested locally Tomcat 10.0.1 with Apache Wicket (9.x,
master). Nothing more.
Tomcat 10.0.x is not production ready so it is too early to do anything
about Jakarta APIs in Wicket.
First we need to release Wicket 9.0.0 (with Javax APIs) and then we can
start thinking about Jakarta APIs.



yes exactly, so many frameworks are going to do that (wait)
So not release any artifacts that use the new jakarta api's
So that means that for many people they can't start test or use Tomcat 10..
Because who is using plain servlet api only?
Any 3rd part dependency is your code  that uses some javax.servlet package
needs to make a special release..
This will take ages, not to mention will only be really done for the latest
releases of those packages (like Wicket 9)


There is no official release of Jakarta EE 9 yet!
I didn't even bother to replace javax.servlet:servlet-api Maven dependency
with the Jakarta one in Wicket.
I just used https://github.com/apache/tomcat-jakartaee-migration to migrate
(already built) wicket-examples.war and it worked fine!
Later I tried to do the same with a Spring Boot based application but the
migration tool faced some problems with the nested archives in Boot's
special packaging.

Tomcat 10.0.x is for early adopters to test it and report issues. But as
Chris suggested we should make this more clear in the docs!
I've committed some improvements. If anyone have more ideas for improvement
I'll be happy to apply them! :-)


Thank you for that Martin. I installed 10.0.x today, and as expected it
broke because all my servlets are based on javax. I grabbed a copy of
the migration tool. Sadly (for me) it required Maven to build, but after
some hesitency, I grabbed Maven and installed that (it was really easy).

With Maven installed and working, I built the migration tool. Again,
easy. With the tool built I simply converted both of my application's
war files, copied them over the originals in webapps, started TC 10 and
everything worked!

So I guess I'm "ready" for TC10 now. :-)

-R


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: tomcat 7.0.100 AJP connector with mod_jk on another host

[Thomas Glanzmann]

Hello,
the problem was that I edited the wrong server.xml. The one that was not
used. So now that I figured that out, settings these two settings help.
























However when I try to access this using mod_jk, I get a 403. I used a sniffer
and it is coming from the AJP connector. So I tried to set
allowedRequestAttributesPattern=".*" but that did not solve my problems, any
ideas?

Setup is:

apache with mod_jk 1.2.46 load balances over 4 tomcats on seperate hosts.

Cheers,
Thomas

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

tomcat 7.0.100 AJP connector with mod_jk on another host

[Thomas Glanzmann]

Hello,
I've just upgraded to tomcat7 (7.0.100) afterwards I'm unable to
reconfigure it to the pre 7.0.100 behaviour where AJP connector listens
on the public ip address in order to use it with mod_jk. Can someone
help me out to make it works again? My server.xml is:
























The issue seems to be, that even when I add the address property to the above
AJP connector, it does not listen on its internal ip address so it can not be
reached from mod_jk which is running on another host:

(tomcat-06) [/etc/tomcat7] lsof -P -i -n | grep -i tomcat
java  29094 tomcat7   16u  IPv6 4315605  0t0  TCP *:46937 (LISTEN)
java  29094 tomcat7   17u  IPv6 4315606  0t0  TCP *:3000 (LISTEN)
java  29094 tomcat7   19u  IPv6 4316198  0t0  TCP *:42795 (LISTEN)
java  29094 tomcat7   56u  IPv6 4278035  0t0  TCP *:8080 (LISTEN)
java  29094 tomcat7   57u  IPv6 4278036  0t0  TCP 127.0.0.1:8009 
(LISTEN)
java  29094 tomcat7  238u  IPv6 4316200  0t0  TCP 127.0.0.1:8005 
(LISTEN)

Cheers,
Thomas

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

Tomcat 9.0.31 Invalid character found in the request target

[Bhavesh Mistry]

Hi Tomcat Team,

When there is invalid characters, it return error message with
stacktrace as shown below.  1) is there any way to costmize error
message ? if yes, please let me know.

2) Is there any way to spress stack-trace being shown on 400 bad request ?

3) Based on Accept header (application/json), can JSON error be
constructed instead of html since client request application/json ?

Thank you for help in advance.

Thanks,

Bhavesh

Request :
===
GET 
/API/?where=type*!*%3d1%20UNION%20SELECT%20version(),null,null,null=true=0=10
HTTP/1.1
Host: 10.192.58.135
Connection: close*Accept: application/json*
Sec-Fetch-Dest: empty
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122
Safari/537.36
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9







Response :
=
HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 1988
Date: Sun, 01 Mar 2020 06:09:41 GMT
Connection: close

HTTP Status 400 – Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 – Bad RequestType
Exception ReportMessage Invalid character found in the
request target. The valid characters are defined in RFC 7230 and RFC
3986Description The server cannot or will not process
the request due to something that is perceived to be a client error
(e.g., malformed request syntax, invalid request message framing, or
deceptive request
routing).Exceptionjava.lang.IllegalArgumentException:
Invalid character found in the request target. The valid characters
are defined in RFC 7230 and RFC 3986

org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:469)

org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:260)

org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)

org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)

org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1639)

org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

java.basejava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

java.basejava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.basejava.lang.Thread.run(Thread.java:834)
Note The full stack trace of the root cause is
available in the server logs.Apache Tomcat
Version X

Re: Tomcat 9 : relaxedQueryChars

[Mark Thomas]

On 04/03/2020 20:20, Robert Hicks wrote:
> We are getting the following over and over in our catalina.out file:
> 
> java.lang.IllegalArgumentException: Invalid character found in the request
> target. The valid characters are defined in RFC 7230 and RFC 3986

Do you know what URIs are triggering those?

We recently improved the HTTP header logging to report invalid
characters in %nn form. We could add that to this exception message so
you have some chance of figuring out what the issue is.

> Our server.xml has the following copied from an online search I think:
> 
> relaxedQueryChars="[]|{}^"

That is all of the allowed characters.

It is an attribute value so you'll need to encode at least " and <. Wjat
you have above is fine.

> I found something else that said the following might also help in
> catalina.properties:
> 
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

I'd be very careful using that.


Mark

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

Tomcat 9 : relaxedQueryChars

[Robert Hicks]

We are getting the following over and over in our catalina.out file:

java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986

Our server.xml has the following copied from an online search I think:

relaxedQueryChars="[]|{}^"


However, the docs say that only the following are valid and others are
ignored:


" < > [ \ ] ^ ` { | }


Do the characters have to be exactly like that instead of encoding them?
For example:


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


I found something else that said the following might also help in
catalina.properties:


org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true


Thanks for any help.


--

Bob

Re: Fix for the Ghostcat vulnerability

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave,

On 3/4/20 05:45, Dave Ford wrote:
> On Wed, 2020-03-04 at 10:24 +0100, Jürgen Göres wrote:
>>
>> If it is, what is the recommended mitigation? We consider using
>> the "secret" feature (the filtering by request attributes is
>> infeasible for us), but that would be a bit of effort and we are
>> in a hurry.
>>
>
> We're in the same position as you.  External web servers talking
> to Tomcat servers on other boxes via AJP.

Are those connections properly secured?

> We've looked at a few options, none of which seemed great:
>
> * The current stable version of Apache doesn't support the
> 'secret' attribute for AJP connectors in mod_proxy.
>
> * Valves can be used to secure Tomcat from listening to certain
> IPs Hostnames or subnets/vlans.  But
>
> * The RemoteCIDRValve affects every protocol/port. * The
> RemoteHostValve and RemoteAddrValve only allow a single allow or
> deny rule, which needs a regexp to match every required
> combinations of port and address/names for the whole of the desired
> context.
>
> In ours case, we'd want to permit a different set of hosts on AJP
> to those who can read the manager app, for instance.  As this is
> being managed by puppet at our end, we decided the required regexp
> would be too complex and breakable and are probably going to
> isolate the AJP traffic using a firewall rule via iptables instead
> of relying on any intrinsic Tomcat feature.

If your connections are properly-secured, simply set
secretRequired="false" and move on. If they aren't properly-secured,
then you need to fix that (and you had to fix that before this recent
announcement).

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5f8SoACgkQHPApP6U8
pFidVQ//TybnY3LaS8RfuNYx2to518gJBMg0YxO7a81GAP8hSl4cNi/d17HrU8UN
sEiyoFLyFrtTUParyIimrHTzrlNjnL/SkbSZk2WsOXpmZ5zDreCDYrIkzreMavJ1
9PhzWUnGXpXvhkosyy25Xba3L/8aVpimqXp7dbyhzt1BiYpD/Ky6HS+AbIf2n2Y4
A+m4squvLkjw6hVt+cyP9bDi/JKdjKWoE70Yhp5o8FkmsZO+qd5Jc211HAnToJx9
LX/aq6RP89w5bNEi7lrcaelLLnWkdpulkXKNPaopK/i3YXbmmD7gd93oux5HXT/M
Vi4y+aFZg29R+ujV8eN5g5f5u0Zi8SbvDr8e+P4fQEWNEkCkp0nlEqtKsmn9uA7m
RH2VbI6l375iQMpbQK3P1A67CdnmdYlPqS5xT+BLXPFhGFUPadv3JW8WNKrZc5+H
UQxQrBIlQ623PlJhkg/seGmLzSnhFUKI0SxdzChzDy3FMyniMNHazdLZoGShmNEs
0YTOqJMSyA4Dq7WBV8Fx4VRUp/gnYKqnUqaCvaHweUhhvYfEFDvDacLlJvqJxr6J
rU0PbZKnqz6D7QR+BAlrebTta9df3hmOoPSNgnc6t63mrT4Ry4XspVm85YMl/7yU
gc62x4cwCGxMpiBIGLd5zVzBcXvZ1An9aZZzqkor+DZ8Z1rGFIs=
=fNQ0
-END PGP SIGNATURE-

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

g! shell 255 character limit

[Iowa Research]

I am encountering a 255 character limit in the g! shell when running Tomcat
9.0.31. I do not see the issue in Tomcat 7. I have searched for solutions
to this issue but have been unsuccessful. Any help is greatly appreciated.

Re: Tomcat 9.0.16 Packaging Change (Extras)

[Stephen Hames]

Hi Mark,

-Dcom.sun.management.jmxremote.registry.ssl=false solved the problem.

Thanks for that.

Regards,
Stephen

On Wed, 4 Mar 2020 at 18:09, Mark Thomas  wrote:

> On 04/03/2020 06:45, Stephen Hames wrote:
> > Hi Mark,
> >
> > Apologies for the very late reply here.  I had to set the upgrade aside
> > temporarily...
> >
> > Steps to reproduce:
> >
> > server.xml snippet
> >
> >  > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> > rmiRegistryPortPlatform="10001"
> > rmiServerPortPlatform="10002"
> > />
> >
> > java options:
> > -Dcom.sun.management.jmxremote.ssl=false
> > -Dcom.sun.management.jmxremote.authenticate=true
> > -Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
> > -Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access
> >
> > When I try to connect with valid credentials using Jconsole, the error
> > observed is: non-JRMP server at remote endpoint
> >
> > If I add catalina-jmx-remote.jar from tomcat 9.0.14 to
> $CATALINA_BASE/lib,
> > and restart, I am able to connect without issue.
>
> The refactoring in 9.0.16 introduced an additional configuration
> requirement:
>
> -Dcom.sun.management.jmxremote.registry.ssl=false
>
> I'll get that added to the documentation.
>
> It is worth noting that with current JVMs there is no need for the
> JmxRemoteLifecycleListener at all. All of the configuration options it
> provides are now available via system properties. Details at:
>
>
> https://tomcat.apache.org/tomcat-9.0-doc/monitoring.html#Enabling_JMX_Remote
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 


This message may
contain confidential and privileged information. If it 
has been sent to you in
error, please reply to advise the sender of the 
error and then immediately
delete this message.

Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Martin Grigorov]

On Wed, Mar 4, 2020 at 4:02 PM Johan Compagner 
wrote:

> >
> >
> > > Or for now generate 2 build artifacts? (as long as it is really just
> the
> > > package rename)
> > >
> >
> > Hm, no. I just tested locally Tomcat 10.0.1 with Apache Wicket (9.x,
> > master). Nothing more.
> > Tomcat 10.0.x is not production ready so it is too early to do anything
> > about Jakarta APIs in Wicket.
> > First we need to release Wicket 9.0.0 (with Javax APIs) and then we can
> > start thinking about Jakarta APIs.
> >
> >
> yes exactly, so many frameworks are going to do that (wait)
> So not release any artifacts that use the new jakarta api's
> So that means that for many people they can't start test or use Tomcat 10..
> Because who is using plain servlet api only?
> Any 3rd part dependency is your code  that uses some javax.servlet package
> needs to make a special release..
> This will take ages, not to mention will only be really done for the latest
> releases of those packages (like Wicket 9)
>

There is no official release of Jakarta EE 9 yet!
I didn't even bother to replace javax.servlet:servlet-api Maven dependency
with the Jakarta one in Wicket.
I just used https://github.com/apache/tomcat-jakartaee-migration to migrate
(already built) wicket-examples.war and it worked fine!
Later I tried to do the same with a Spring Boot based application but the
migration tool faced some problems with the nested archives in Boot's
special packaging.

Tomcat 10.0.x is for early adopters to test it and report issues. But as
Chris suggested we should make this more clear in the docs!
I've committed some improvements. If anyone have more ideas for improvement
I'll be happy to apply them! :-)

Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Johan Compagner]

>
>
> > Or for now generate 2 build artifacts? (as long as it is really just the
> > package rename)
> >
>
> Hm, no. I just tested locally Tomcat 10.0.1 with Apache Wicket (9.x,
> master). Nothing more.
> Tomcat 10.0.x is not production ready so it is too early to do anything
> about Jakarta APIs in Wicket.
> First we need to release Wicket 9.0.0 (with Javax APIs) and then we can
> start thinking about Jakarta APIs.
>
>
yes exactly, so many frameworks are going to do that (wait)
So not release any artifacts that use the new jakarta api's
So that means that for many people they can't start test or use Tomcat 10..
Because who is using plain servlet api only?
Any 3rd part dependency is your code  that uses some javax.servlet package
needs to make a special release..
This will take ages, not to mention will only be really done for the latest
releases of those packages (like Wicket 9)

Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Martin Grigorov]

Hi Johan,

On Wed, Mar 4, 2020 at 10:34 AM Johan Compagner 
wrote:

> Martin :)
>
> exactly my point.. so Wicket now needs to have 2 branches right? that are
> the same except for the package rename for a long time
> (so kind of having 2 masters)
>
> Or for now generate 2 build artifacts? (as long as it is really just the
> package rename)
>

Hm, no. I just tested locally Tomcat 10.0.1 with Apache Wicket (9.x,
master). Nothing more.
Tomcat 10.0.x is not production ready so it is too early to do anything
about Jakarta APIs in Wicket.
First we need to release Wicket 9.0.0 (with Javax APIs) and then we can
start thinking about Jakarta APIs.

Martin


>
> On Wed, 4 Mar 2020 at 09:14, Martin Grigorov  wrote:
>
> > Hi Johan,
> >
> > On Mon, Mar 2, 2020 at 7:32 PM Johan Compagner 
> > wrote:
> >
> > > And when you are at it, also mention there in big letters that they
> > really
> > > should read the release notes... This tomcat will not work with all the
> > > major frameworks people use for quite some time...
> > >
> >
> > If you still use Apache Wicket (and I bet you do! :-) ) I've tested it
> > successfully on 10.0.0-M1 for you:
> > https://twitter.com/mtgrigorov/status/1225359299570028546
> >
> > But I agree that this information should be emphasized in Tomcat docs!
> > I'll update the website!
> >
> > Martin
> >
> >
> > >
> > > Op ma 2 mrt. 2020 18:23 schreef Christopher Schultz <
> > > ch...@christopherschultz.net>:
> > >
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > >
> > > > All,
> > > >
> > > > If you go to tomcat.apache.org right now, you'll see documentation
> and
> > > > downloads for Tomcat 10. In the news section, it's shown as 10.0.0-M1
> > > > so that might be an indication that it's not a "normal" release.
> > > >
> > > > Anyone going to the site and not reading the (current) top-item of
> > > > news might think that Tomcat 10 is the current best version to
> > download.
> > > >
> > > > I propose the following:
> > > >
> > > > 1. Add a [beta] (or similar) badge to the [Tomcat 10] download and
> > > > [Tomcat 10.0] documentation links.
> > > >
> > > > 2. On the "which version" page, add a [beta] (or similar) badge to
> the
> > > > Tomcat 10 release
> > > >
> > > > 3. On the Tomcat 10 downloads page, in the summary section, add a
> very
> > > > prominent statement that says Tomcat 10 is in [beta] or similar. I
> > > > might even use a large font and/or red or some other
> > > > attention-grabbing text color.
> > > >
> > > > 4. Similar to [3] above, but on the Tomcat 10 documentation page
> > > > introduction.
> > > >
> > > > WDYT?
> > > >
> > > > - -chris
> > > > -BEGIN PGP SIGNATURE-
> > > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> > > >
> > > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5dQOkACgkQHPApP6U8
> > > > pFglHA//XKKCS260Hvx+gA5YshiPYOpKS7FOG/bDzef9Y+JqMpuFMrOt/7d2AG2/
> > > > X7GqQ57mJ+aew5p+nncXWV5yXd3fGyhPCeDsdF5pNc3K87dYs0MZCt/5nB9D2mJK
> > > > 3uoRQjQscwo2pBuozpBViw19HoeoEjQGWHWrs60LTckODDQj1IcT6zZUgckGkMaP
> > > > sPu1x+kra+5psKWtK91S6KOERoYQ13gNhIAIlEgCavLzwOoyz3El5/9iXne2rP/w
> > > > tePV+1e9r7ltF6WBJtA72xMAS1mXvK+bW1Wpm/5dMicpnRF04vaOUlZularWgbvO
> > > > 8p67YCJ3keaVtKcfDVHxSUVUUbjroWX9beoOnTDujw6zUapoKzibtU9EEyEOQXIW
> > > > C946ZhyPjS6I+liRHGQHKkQgBMUpHC+WGmasC5RW6+hySJCTjp6TGKlr5vuDk0th
> > > > OtcuHgzaOoqqVjYOZwArQi96c0l5/RW/6wxseunvK5n8TzP/l3F5jP627dUodsWV
> > > > B1qQfP3aePMGaTnRDuookTBoS1FLANc2Fc0m6hpTJmVkgcrYSFo4vmlljSGUCSkB
> > > > rUzY10W3rLu467ipcoFEzMGgVmM0cO29qk35JqPj0DtZa5BbFQTQa95iERxnRx45
> > > > izIC7Nz5+UUdjdcoMhIVMdq/oA1TC++MXpRMOoYlOpnOf7hT+yo=
> > > > =nLsr
> > > > -END PGP SIGNATURE-
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >
> > > >
> > >
> >
>
>
> --
> Johan Compagner
> Servoy
>

Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Martin Grigorov]

Hi,

On Mon, Mar 2, 2020 at 7:23 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> If you go to tomcat.apache.org right now, you'll see documentation and
> downloads for Tomcat 10. In the news section, it's shown as 10.0.0-M1
> so that might be an indication that it's not a "normal" release.
>
> Anyone going to the site and not reading the (current) top-item of
> news might think that Tomcat 10 is the current best version to download.
>
> I propose the following:
>
> 1. Add a [beta] (or similar) badge to the [Tomcat 10] download and
> [Tomcat 10.0] documentation links.
>
> 2. On the "which version" page, add a [beta] (or similar) badge to the
> Tomcat 10 release
>
> 3. On the Tomcat 10 downloads page, in the summary section, add a very
> prominent statement that says Tomcat 10 is in [beta] or similar. I
> might even use a large font and/or red or some other
> attention-grabbing text color.
>
> 4. Similar to [3] above, but on the Tomcat 10 documentation page
> introduction.
>
> WDYT?
>

I've added 'alpha' after all occurrences of
10.0.x. I've chose 'alpha' as in the VOTE thread.
The navigation menu is generated by XSLT and I wasn't able to render proper
HTML so it is just '(alpha)' there.

I've also fixed the link to download 10.0.1 the the news entry.

Martin


>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5dQOkACgkQHPApP6U8
> pFglHA//XKKCS260Hvx+gA5YshiPYOpKS7FOG/bDzef9Y+JqMpuFMrOt/7d2AG2/
> X7GqQ57mJ+aew5p+nncXWV5yXd3fGyhPCeDsdF5pNc3K87dYs0MZCt/5nB9D2mJK
> 3uoRQjQscwo2pBuozpBViw19HoeoEjQGWHWrs60LTckODDQj1IcT6zZUgckGkMaP
> sPu1x+kra+5psKWtK91S6KOERoYQ13gNhIAIlEgCavLzwOoyz3El5/9iXne2rP/w
> tePV+1e9r7ltF6WBJtA72xMAS1mXvK+bW1Wpm/5dMicpnRF04vaOUlZularWgbvO
> 8p67YCJ3keaVtKcfDVHxSUVUUbjroWX9beoOnTDujw6zUapoKzibtU9EEyEOQXIW
> C946ZhyPjS6I+liRHGQHKkQgBMUpHC+WGmasC5RW6+hySJCTjp6TGKlr5vuDk0th
> OtcuHgzaOoqqVjYOZwArQi96c0l5/RW/6wxseunvK5n8TzP/l3F5jP627dUodsWV
> B1qQfP3aePMGaTnRDuookTBoS1FLANc2Fc0m6hpTJmVkgcrYSFo4vmlljSGUCSkB
> rUzY10W3rLu467ipcoFEzMGgVmM0cO29qk35JqPj0DtZa5BbFQTQa95iERxnRx45
> izIC7Nz5+UUdjdcoMhIVMdq/oA1TC++MXpRMOoYlOpnOf7hT+yo=
> =nLsr
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: issue faced in tomcat 8.5.51

[Dave Ford]

On Fri, 2020-02-28 at 13:39 +, Rathore, Rajendra wrote:
> Caused by: java.lang.IllegalArgumentException: The AJP Connector is
> configured with secretRequired="true" but the secret attribute is
> either null or "". This combination is not valid.

Are you talking to this via an apache webserver using mod_proxy_ajp?
Only, the current stable release of apache (2.4.41) doesn't support
'secret' AFAIK. 

See 

https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html

and

https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=53098

Note the above 'bug' in Apache is only 12 years old :-(

Dave

Re: Fix for the Ghostcat vulnerability

[Dave Ford]

On Wed, 2020-03-04 at 10:24 +0100, Jürgen Göres wrote:
> 
> If it is, what is the recommended mitigation? We consider using the
> "secret" feature (the filtering by request attributes is infeasible
> for us), but that would be a bit of effort and we are in a hurry.
> 

We're in the same position as you.  External web servers talking to
Tomcat servers on other boxes via AJP.

We've looked at a few options, none of which seemed great:

* The current stable version of Apache doesn't support the 'secret'
attribute for AJP connectors in mod_proxy.

* Valves can be used to secure Tomcat from listening to certain IPs
Hostnames or subnets/vlans.  But 

* The RemoteCIDRValve affects every protocol/port. 
* The RemoteHostValve and RemoteAddrValve only allow a single allow or
deny rule, which needs a regexp to match every required combinations of
port and address/names for the whole of the desired context.  

In ours case, we'd want to permit a different set of hosts on AJP to
those who can read the manager app, for instance.  As this is being
managed by puppet at our end, we decided the required regexp would be
too complex and breakable and are probably going to isolate the AJP
traffic using a firewall rule via iptables instead of relying on any
intrinsic Tomcat feature.

Dave

Re: Fix for CVE-2020-1938

[Mark Thomas]

I assume from context that you mean CVE-2020-1938.

Ghostcat is the name of a malware strain that has been around since at
least October last year. When referencing vulnerabilities it is best to
stick to the CVE reference since they should be unique (and if something
goes wrong and they aren't there are procedures to get them re-issued so
they are).

> we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the AJP 
> protocol since we use Apache HTTPD as reverse proxy and found it to be mostly 
> hazzle-free over the last few years, so we would like to continue using it.
> Since the HTTPD and the Tomcats are in general not on the same nodes, the AJP 
> connector has to listen on all interfaces.
> My first question is: what value do I need to set in the "address" attribute 
> to indicate that I want the connector to listen on ALL interfaces (for IPv4 
> AND IPv6)? Maybe that should be documented. :-)

It will vary by system. Some systems can't listen on both IPv4 and IPv6
with a single socker. Usually either "::" or "0.0.0.0" will have the
desired result.

> So the question is: is the root cause actually fixed?

Yes.

> Or will an AJP connector that is (perhaps by accident) exposed still be 
> vulnerable to the vulnerability?

No.

CVE-2020-1938 is primarily about the ability to obtain any file from the
web application and/or process any file from the web application as a
JSP. The changes for CVE-2020-1938 block this by default.

The very nature of the AJP protocol is such that clients have to be trusted.
Tomcat trusts the "real" client IP address provided. That could be used
for access control.
Tomcat may be configured to trust the authenticated user name provided.
That almost certainly will then be used for access control.

There was a discussion late last year within the Tomcat Security Team
whether it was necessary to provide a more secure by default
configuration for AJP. We were considering disabling by default in
Tomcat 10. It became apparent during the investigation of CVE-2020-1938
that there were a large number of Tomcat instances where the AJP port
was exposed directly to the internet. We therefore took the decision to
make a number of changes to make AJP more secure by default and require
that system administrators had to provide explicit configuration (so
hopefully they would think about what they were doing) to relax those
security restrictions.

> If it is, what is the recommended mitigation? We consider using the "secret" 
> feature (the filtering by request attributes is infeasible for us), but that 
> would be a bit of effort and we are in a hurry.

It would be unusual for an application to be using request attributes
directly. These have to be explicitly set in the reverse proxy and are
normally used for the reverse proxy to pass information to Tomcat about
the client etc.

How to mitigate will vary on a case by case basis. There will be some
systems where exposing an AJP port to the internet is not a security
concern. I still wouldn't recommend doing it but I can see how a case
could be made.

In short, you need to find a way to ensure that only trusted clients
(reverse proxies) can use the AJP port.

If the reverse proxy and Tomcat are on the same box you can use the
loopback address if you trust all the users which access to the box
(since they could log on and issue requests directly to the AJP port).

If the reverse proxy and Tomcat are on different boxes then you have
various options:
 - setting up a dedicated subnet for reverse proxy to Tomcat
   communication;
 - configuring a firewall on the Tomcat box to only accept connections
   to the AJP port from specific hosts

For any network configuration you can configure a shared secret for the
reverse proxy workers and the AJP connector.

Which approach, or combination of approaches, will work best for any one
user will vary from user to user.

Mark


>  
> Regards
>  
> JG
>  
> 
> -
> 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.16 Packaging Change (Extras)

[Mark Thomas]

On 04/03/2020 06:45, Stephen Hames wrote:
> Hi Mark,
> 
> Apologies for the very late reply here.  I had to set the upgrade aside
> temporarily...
> 
> Steps to reproduce:
> 
> server.xml snippet
> 
>  className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> rmiRegistryPortPlatform="10001"
> rmiServerPortPlatform="10002"
> />
> 
> java options:
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.authenticate=true
> -Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
> -Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access
> 
> When I try to connect with valid credentials using Jconsole, the error
> observed is: non-JRMP server at remote endpoint
> 
> If I add catalina-jmx-remote.jar from tomcat 9.0.14 to $CATALINA_BASE/lib,
> and restart, I am able to connect without issue.

The refactoring in 9.0.16 introduced an additional configuration
requirement:

-Dcom.sun.management.jmxremote.registry.ssl=false

I'll get that added to the documentation.

It is worth noting that with current JVMs there is no need for the
JmxRemoteLifecycleListener at all. All of the configuration options it
provides are now available via system properties. Details at:

https://tomcat.apache.org/tomcat-9.0-doc/monitoring.html#Enabling_JMX_Remote

Mark

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

Fix for the Ghostcat vulnerability

[Jürgen Göres]

Hi,
 
we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the AJP 
protocol since we use Apache HTTPD as reverse proxy and found it to be mostly 
hazzle-free over the last few years, so we would like to continue using it.
Since the HTTPD and the Tomcats are in general not on the same nodes, the AJP 
connector has to listen on all interfaces.
My first question is: what value do I need to set in the "address" attribute to 
indicate that I want the connector to listen on ALL interfaces (for IPv4 AND 
IPv6)? Maybe that should be documented. :-)
 
It is clear that the AJP ports should not be exposed to the end users (let 
alone the public internet ;-)) and we of course make sure that this is the case 
for our SaaS hosting, but on-premise customers tend to ignore the security 
guidelines we provide with our product and might have AJP connectors not 
firewalled off.
So it could be that there are installations out there which have the AJP ports 
exposed. 
 
This leads me to trhe next question is about the fixes themselves. I checked 
the changelists mentioned on these pages:
https://tomcat.apache.org/security-8.html#Fixed_in_Apache_Tomcat_8.5.51
https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.31
 
>From what I gathered, these changes only disable the AJP connector by default, 
>change the listining interface to loopback (from "all interfaces"), add a 
>feature to filter requests by request attributes and change the way the 
>optional secret used between HTTPD and Tomcat is configured.
I could not see any changes that actually resolve the issue in the AJP 
connector's implementation that allow the exploit. 
So the question is: is the root cause actually fixed? Or will an AJP connector 
that is (perhaps by accident) exposed still be vulnerable to the vulnerability?
 
If it is, what is the recommended mitigation? We consider using the "secret" 
feature (the filtering by request attributes is infeasible for us), but that 
would be a bit of effort and we are in a hurry.
 
Regards
 
JG
 

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

Re: Severe problem when migrating from tomcat v7.0.99 to 7.0.100?

[Mark Thomas]

On 04/03/2020 09:04, michael.b...@arctis.at wrote:
> Hello,
> 
> We are currently fighting with the tomcat update from v7.0.99 to
> v7.0.100. Since there are open security issues in v7.0.99 we are forced
> to do it promptly, however I have the feeling that we detected a major
> issue in v7.0.100.

Known issue (SCI support was broken) already fixed in 7.0.x for 7.0.101
onwards.

Mark

> 
>  
> 
> We have a Faces-Application, based on org=”org.glassfish"
> name="javax.faces" rev="2.3.9”.
> 
> It seems that v7.0.100 does not load the FacesInitializer, declared in
> /META-INF/services/javax.servlet.ServletContainerInitializer, whereas
> v7.0.99 does.
> 
> The FacesInitializer initializes, e.g. classes annotated with
> @FacesConverter or @FacesValidator, which won’t be available any more.
> 
>  
> 
> It seems related with the following entries in the changelog:
> 
>  
> 
>  
> 
> fix
> 
>   
> 
> 64021 : Ensure
> that container provided SCIs are always loaded before application
> provided SCIs. Note that where both the container and the application
> provide the same SCI, it is the application provided SCI that will be
> used. (markt)
> 
> fix
> 
>   
> 
> SCI definitions from JARs unpacked into |WEB-INF/classes|are now handled
> consistently and will always be found irrespective of whether the web
> application defines a JAR ordering or not. (markt)
> 
>  
> 
>  
> 
> Our current workaround is, to copy the file
> /META-INF/services/javax.servlet.ServletContainerInitializer Into the
> WEB-INF/classes – Folder.
> 
>  
> 
> Before filing this as a Bug Report, I would like to post it in this
> forum to get feedback. To demonstrate the issue, I provided a simple
> demonstration war-Project via a temporary download link:
> http://server.arctis.at/tmp/ProblemDemoProject.war
> 
>  
> 
> Depending on your installation, the call to
> https://localhost:8443/ProblemDemoProject/ should return in v7.0.99
> something like
> 
> Startvalue: Hello World
> 
> Converted value: HELLO WORLD (converted by DemoConverter
> 
>  
> 
> With v7.0.100 it returns
> 
>  
> 
> An Error Occurred:
> 
>  
> 
> Ausdrucksfehler: Benanntes Objekt demoConverter nicht gefunden. 
> 
> (sorry German localization: should read expression error: named object
> demoConverter not found)
> 
>  
> 
> …
> 
>  
> 
> 04.03.2020 08:51:07 - Generated by Mojarra/Facelets
> 
>  
> 
> Feedback welcome.
> 
>  
> 
> As an addendum: Meanwhile I have detected
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 .
> 
> I’m pretty sure that the problem is related with it. Just use my demo
> web application for an regression test .
> 
>  
> 
> Michael
> 
>  
> 
> Dr. Michael Breu
> 
> michael.b...@arctis.at
>   Tel. +43
> 676 3439918
> 
> arctis Softwaretechnologie GmbH,    GF. Dr. Michael Breu
> 
> 6401 Inzing, Jägerweg 2   Firmenbuch FN 230395 t
> 
>  
> 


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

Severe problem when migrating from tomcat v7.0.99 to 7.0.100?

[Michael.Breu]

Hello,

 

We are currently fighting with the tomcat update from v7.0.99 to v7.0.100. 
Since there are open security issues in v7.0.99 we are forced to do it 
promptly, however I have the feeling that we detected a major issue in v7.0.100.

 

We have a Faces-Application, based on org=”org.glassfish" name="javax.faces" 
rev="2.3.9”. 

It seems that v7.0.100 does not load the FacesInitializer, declared in 
/META-INF/services/javax.servlet.ServletContainerInitializer, whereas v7.0.99 
does.

The FacesInitializer initializes, e.g. classes annotated with @FacesConverter 
or @FacesValidator, which won’t be available any more.

 

It seems related with the following entries in the changelog:

 

 




  64021: Ensure that 
container provided SCIs are always loaded before application provided SCIs. 
Note that where both the container and the application provide the same SCI, it 
is the application provided SCI that will be used. (markt) 




SCI definitions from JARs unpacked into WEB-INF/classes are now handled 
consistently and will always be found irrespective of whether the web 
application defines a JAR ordering or not. (markt) 

 

 

Our current workaround is, to copy the file 
/META-INF/services/javax.servlet.ServletContainerInitializer Into the 
WEB-INF/classes – Folder.

 

Before filing this as a Bug Report, I would like to post it in this forum to 
get feedback. To demonstrate the issue, I provided a simple demonstration 
war-Project via a temporary download link: 
http://server.arctis.at/tmp/ProblemDemoProject.war

 

Depending on your installation, the call to 
https://localhost:8443/ProblemDemoProject/ should return in v7.0.99 something 
like

Startvalue: Hello World

Converted value: HELLO WORLD (converted by DemoConverter

 

With v7.0.100 it returns

 

An Error Occurred:

 

Ausdrucksfehler: Benanntes Objekt demoConverter nicht gefunden.  

(sorry German localization: should read expression error: named object 
demoConverter not found)

 

…

 

04.03.2020 08:51:07 - Generated by Mojarra/Facelets

 

Feedback welcome.

 

As an addendum: Meanwhile I have detected  
 
https://bz.apache.org/bugzilla/show_bug.cgi?id=64191 . 

I’m pretty sure that the problem is related with it. Just use my demo web 
application for an regression test . 

 

Michael

 

Dr. Michael Breu

michael.b...@arctis.at  
  Tel. +43 676 3439918

arctis Softwaretechnologie GmbH,GF. Dr. Michael Breu

6401 Inzing, Jägerweg 2   Firmenbuch FN 230395 t

 

Re: cookie configurations for Tomcat 7

[Lazar Kirchev]

Chris, Martin,

Here is the PR: https://github.com/apache/tomcat/pull/252

Lazar

On Sat, Feb 29, 2020 at 8:27 AM Martin Grigorov 
wrote:

> On Fri, Feb 28, 2020 at 7:31 PM Lazar Kirchev 
> wrote:
>
> > Chris,
> >
> > I just thought that I have some concerns passing a map with the headers
> to
> > generateCookie() method. This means that for each call the caller will
> have
> > to read all headers from the coyote.Response and put them in a map, even
> if
> > the CookieProcessor will not need them, as is the case with the legacy
> > cookie processor and the rfc cookie processor. This might have
> performance
> > impact. Isn't it more optimal to just pass the o.a.c.connector.Request -
> > like generateCookie (Request, Cookie) - and then if the cookie processor
> > implementation needs headers, it will take them - only these which it
> needs
> > - from the Response.
> > What do you think?
> >
>
> I agree that this is a better way!
>
> Martin
>
>
> >
> > Lazar
> >
> > On Fri, Feb 28, 2020, 17:08 Lazar Kirchev 
> wrote:
> >
> > >
> > > Chris,
> > >
> > > Actually in my preferred option the implementation in the
> > > CookieProcessorBase should not be no-op, but it should call
> > > CookieProcessor.generateCookie(Cookie). And the calls to
> > > CookieProcessor.generateCookie(Cookie) in o.a.c.connector.Response and
> > > o.a.c.core.ApplicationPushBuilder should be replaced with calls to the
> > new
> > > method.
> > >
> > > Lazar
> > >
> > > On Fri, Feb 28, 2020 at 3:58 PM Lazar Kirchev  >
> > > wrote:
> > >
> > >> Chris,
> > >>
> > >> Yes, I will prepare a PR in the next days. However, as Tomcat 8.5
> should
> > >> be able to work both on Java 7 and Java 8, interface default methods
> > can't
> > >> be used. So would you prefer to have a second
> > CookieProcessor.generateCookie(Map<>
> > >> requestHeaders, Cookie) in addition to the existing
> > CookieProcessor.generateCookie(Cookie),
> > >> and provide a no-op implementation in the CookieProcessorBase class,
> or
> > to
> > >> change the signature of the existing method instead? I myself prefer
> the
> > >> first option, with adding a second method.
> > >>
> > >> Lazar
> > >>
> > >> On Mon, Feb 24, 2020 at 5:19 PM Christopher Schultz <
> > >> ch...@christopherschultz.net> wrote:
> > >>
> > >>> -BEGIN PGP SIGNED MESSAGE-
> > >>> Hash: SHA256
> > >>>
> > >>> Lazar,
> > >>>
> > >>> On 2/24/20 02:05, Lazar Kirchev wrote:
> > >>> > Chris,
> > >>> >
> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie) will
> > >>> > work perfectly for me and I guess for anyone who needs to check the
> > >>> > client version.
> > >>>
> > >>> Want to prepare a PR?
> > >>>
> > >>> - -chris
> > >>>
> > >>> > On Fri, Feb 21, 2020 at 7:17 PM Christopher Schultz <
> > >>> > ch...@christopherschultz.net> wrote:
> > >>> >
> > >>> > Lazar,
> > >>> >
> > >>> > On 2/21/20 10:29, Lazar Kirchev wrote:
> > >>>  Yes, the SameSite attribute is still in a draft and this
> > >>>  causes the mess, at least partly.> And yes, I was thinking
> > >>>  about something like that -
> > >>>  CookieProcessor.generateCookie(String userAgent, Cookie) or
> > >>>  CookieProcessor.generateCookie(Map<> requestHeaders, Cookie).
> > >>>  I
> > >>> > absolutely
> > >>>  agree that this would be very hacky. And it might be
> > >>>  dangerous as CookieProcessor is an interface and there
> > >>>  already might be custom implementations.
> > >>> >
> > >>> > We can fix that with default implementations, for Java versions
> > >>> > that support such thing (Java >= 1.8).
> > >>> >
> > >>>  But can you think of another way of making the cookie
> > >>>  generation logic aware of the user agent header value?
> > >>> >
> > >>> > Not really.
> > >>> >
> > >>> > I have a preference for:
> > >>> >
> > >>> > CookieProcessor.generateCookie(Map<> requestHeaders, Cookie)
> > >>> >
> > >>> > This is because User-Agent might not be the only header which is
> > >>> > useful, here. For example, Google Chrome (amusingly enough) will
> > >>> > be removing the User-Agent header[1] in favor of "client
> > >>> > hints"[2].
> > >>> >
> > >>> > So you might have to look at more than one header at a time,
> > >>> > including possibly User-Agent.
> > >>> >
> > >>> > -chris
> > >>> >
> > >>> > [1]
> > >>> >
> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-i
> > >>> n-
> > >>> >
> > >>> >
> > >>> chrome/
> > >>> > <
> > https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-
> > >>> in-chrome/
> > >>> <
> >
> https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/
> > >
> > >>> >
> > >>> >
> > >>> >  [2] https://wicg.github.io/ua-client-hints/
> > >>> >
> > >>>  On Fri, Feb 14, 2020 at 8:59 PM Christopher Schultz <
> > >>>  ch...@christopherschultz.net> wrote:
> > >>> 
> > >>>  Lazar,
> > >>> 
> > >>>  On 2/14/20 05:36, Lazar Kirchev wrote:
> > >>> >>> Chris,
> > >>> >>>
> > >>> >>> 

Re: Problem with tomcat connector in IIS using tomcat 9.0.31

[Martin Grigorov]

On Wed, Mar 4, 2020 at 10:30 AM Stephen Hames
 wrote:

> Hi Matthias,
>
> I suspect your issue is: address="::"You probably want
> address="0.0.0.0" or the ipv4 IP address that your tomcat instance is
> listening on.   :: allows any on IPv6, but for IPv4 I suspect that tomcat
> would still be listening only on 127.0.0.1
>

Some users reported that by using 127.0.0.1 there were some latency issues.
Using ::1 resolved these issues for them.
But this issue sounds to me like some problem in the network stack, not in
Tomcat.


>
> Regards,
> Stephen
>
>
> On Wed, 4 Mar 2020 at 15:20, Matthias Fechner  wrote:
>
> > Dear all,
> >
> > as tomcat version 9.0.31 has some security fixes included I tried to do
> > an upgrade.
> > On the IIS tomcat connector version 1.2.46 is installed.
> >
> > As secret I use a 32 character long alpha numeric string, I name it here
> > token.
> > In the workers.properties I tried to define it on the load balancer
> > line:
> > worker.loadbalancer.secret=token
> >
> > And/or on each node:
> > worker.node1.secret=token
> > ...
> > worker.node2.secret=token
> >
> > For the tomcat configuration I defined in server.xml the following AJP
> > connector:
> >   > address="::"
> > port="8009"
> > tomcatAuthentication="false"
> > enableLookups="false"
> > secret="token"
> > redirectPort="8443" />
> >
> > But it does not work. It seems that tomcat does not answer here.
> > If I downgrade to tomcat 9.0.29 it works without any problems.
> >
> > I started then wireshark and had a look into the traffic coming from the
> > IIS.
> >  From IIS is see a AJP13 connection with the following content in "Apache
> > JServ Protocol v1.3" part in wireshark:
> > ...
> > Sec-Fetch-User: ?1
> > token
> > INTERNAL\user
> > Negotiate
> > ...
> >
> > as the token is here included the secret configuration is maybe correct.
> > The token is here equal to the token define on IIS-tomcat-connector and
> > the tomcat server.xml AJP definition.
> > Tomcat is sending back a "0:RSP:SEND HEADERS:403 403"
> >
> > The IIS is doing authentication is is then just sending the user to
> > tomcat.
> >
> > Regarding the documentation everything seems to be configured correctly,
> > but it does not work.
> > Could anyone help me here, please?
> >
> > --
> > Thanks a lot
> > Matthias
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
> --
> _
> Stephen Hames, Systems Architect & Release Manager
> Singapore | +65 6403 5900
> CloudPay 
> --
> _
> Stephen Hames, Systems Architect & Release Manager
> Singapore | +65 6403 5900
> CloudPay 
>
> --
>
>
> This message may
> contain confidential and privileged information. If it
> has been sent to you in
> error, please reply to advise the sender of the
> error and then immediately
> delete this message.
>

Re: Problem with tomcat connector in IIS using tomcat 9.0.31

[tomcat/perl]

On 04.03.2020 09:30, Stephen Hames wrote:

Hi Matthias,

I suspect your issue is: address="::"You probably want
address="0.0.0.0" or the ipv4 IP address that your tomcat instance is
listening on.   :: allows any on IPv6, but for IPv4 I suspect that tomcat
would still be listening only on 127.0.0.1


But then, the error at the IIS level would be "connection refused", no ?
Not a tomcat response with a 403 status, as seems to happen below.
Or am I the confused one ?



Regards,
Stephen


On Wed, 4 Mar 2020 at 15:20, Matthias Fechner  wrote:


Dear all,

as tomcat version 9.0.31 has some security fixes included I tried to do
an upgrade.
On the IIS tomcat connector version 1.2.46 is installed.

As secret I use a 32 character long alpha numeric string, I name it here
token.
In the workers.properties I tried to define it on the load balancer
line:
worker.loadbalancer.secret=token

And/or on each node:
worker.node1.secret=token
...
worker.node2.secret=token

For the tomcat configuration I defined in server.xml the following AJP
connector:
  

But it does not work. It seems that tomcat does not answer here.
If I downgrade to tomcat 9.0.29 it works without any problems.

I started then wireshark and had a look into the traffic coming from the
IIS.
  From IIS is see a AJP13 connection with the following content in "Apache
JServ Protocol v1.3" part in wireshark:
...
Sec-Fetch-User: ?1
token
INTERNAL\user
Negotiate
...

as the token is here included the secret configuration is maybe correct.
The token is here equal to the token define on IIS-tomcat-connector and
the tomcat server.xml AJP definition.
Tomcat is sending back a "0:RSP:SEND HEADERS:403 403"

The IIS is doing authentication is is then just sending the user to
tomcat.

Regarding the documentation everything seems to be configured correctly,
but it does not work.
Could anyone help me here, please?

--
Thanks a lot
Matthias

-
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: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Johan Compagner]

Martin :)

exactly my point.. so Wicket now needs to have 2 branches right? that are
the same except for the package rename for a long time
(so kind of having 2 masters)

Or for now generate 2 build artifacts? (as long as it is really just the
package rename)

On Wed, 4 Mar 2020 at 09:14, Martin Grigorov  wrote:

> Hi Johan,
>
> On Mon, Mar 2, 2020 at 7:32 PM Johan Compagner 
> wrote:
>
> > And when you are at it, also mention there in big letters that they
> really
> > should read the release notes... This tomcat will not work with all the
> > major frameworks people use for quite some time...
> >
>
> If you still use Apache Wicket (and I bet you do! :-) ) I've tested it
> successfully on 10.0.0-M1 for you:
> https://twitter.com/mtgrigorov/status/1225359299570028546
>
> But I agree that this information should be emphasized in Tomcat docs!
> I'll update the website!
>
> Martin
>
>
> >
> > Op ma 2 mrt. 2020 18:23 schreef Christopher Schultz <
> > ch...@christopherschultz.net>:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > All,
> > >
> > > If you go to tomcat.apache.org right now, you'll see documentation and
> > > downloads for Tomcat 10. In the news section, it's shown as 10.0.0-M1
> > > so that might be an indication that it's not a "normal" release.
> > >
> > > Anyone going to the site and not reading the (current) top-item of
> > > news might think that Tomcat 10 is the current best version to
> download.
> > >
> > > I propose the following:
> > >
> > > 1. Add a [beta] (or similar) badge to the [Tomcat 10] download and
> > > [Tomcat 10.0] documentation links.
> > >
> > > 2. On the "which version" page, add a [beta] (or similar) badge to the
> > > Tomcat 10 release
> > >
> > > 3. On the Tomcat 10 downloads page, in the summary section, add a very
> > > prominent statement that says Tomcat 10 is in [beta] or similar. I
> > > might even use a large font and/or red or some other
> > > attention-grabbing text color.
> > >
> > > 4. Similar to [3] above, but on the Tomcat 10 documentation page
> > > introduction.
> > >
> > > WDYT?
> > >
> > > - -chris
> > > -BEGIN PGP SIGNATURE-
> > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> > >
> > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5dQOkACgkQHPApP6U8
> > > pFglHA//XKKCS260Hvx+gA5YshiPYOpKS7FOG/bDzef9Y+JqMpuFMrOt/7d2AG2/
> > > X7GqQ57mJ+aew5p+nncXWV5yXd3fGyhPCeDsdF5pNc3K87dYs0MZCt/5nB9D2mJK
> > > 3uoRQjQscwo2pBuozpBViw19HoeoEjQGWHWrs60LTckODDQj1IcT6zZUgckGkMaP
> > > sPu1x+kra+5psKWtK91S6KOERoYQ13gNhIAIlEgCavLzwOoyz3El5/9iXne2rP/w
> > > tePV+1e9r7ltF6WBJtA72xMAS1mXvK+bW1Wpm/5dMicpnRF04vaOUlZularWgbvO
> > > 8p67YCJ3keaVtKcfDVHxSUVUUbjroWX9beoOnTDujw6zUapoKzibtU9EEyEOQXIW
> > > C946ZhyPjS6I+liRHGQHKkQgBMUpHC+WGmasC5RW6+hySJCTjp6TGKlr5vuDk0th
> > > OtcuHgzaOoqqVjYOZwArQi96c0l5/RW/6wxseunvK5n8TzP/l3F5jP627dUodsWV
> > > B1qQfP3aePMGaTnRDuookTBoS1FLANc2Fc0m6hpTJmVkgcrYSFo4vmlljSGUCSkB
> > > rUzY10W3rLu467ipcoFEzMGgVmM0cO29qk35JqPj0DtZa5BbFQTQa95iERxnRx45
> > > izIC7Nz5+UUdjdcoMhIVMdq/oA1TC++MXpRMOoYlOpnOf7hT+yo=
> > > =nLsr
> > > -END PGP SIGNATURE-
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > >
> > >
> >
>


-- 
Johan Compagner
Servoy

Re: Problem with tomcat connector in IIS using tomcat 9.0.31

[Stephen Hames]

Hi Matthias,

I suspect your issue is: address="::"You probably want
address="0.0.0.0" or the ipv4 IP address that your tomcat instance is
listening on.   :: allows any on IPv6, but for IPv4 I suspect that tomcat
would still be listening only on 127.0.0.1

Regards,
Stephen


On Wed, 4 Mar 2020 at 15:20, Matthias Fechner  wrote:

> Dear all,
>
> as tomcat version 9.0.31 has some security fixes included I tried to do
> an upgrade.
> On the IIS tomcat connector version 1.2.46 is installed.
>
> As secret I use a 32 character long alpha numeric string, I name it here
> token.
> In the workers.properties I tried to define it on the load balancer
> line:
> worker.loadbalancer.secret=token
>
> And/or on each node:
> worker.node1.secret=token
> ...
> worker.node2.secret=token
>
> For the tomcat configuration I defined in server.xml the following AJP
> connector:
>   address="::"
> port="8009"
> tomcatAuthentication="false"
> enableLookups="false"
> secret="token"
> redirectPort="8443" />
>
> But it does not work. It seems that tomcat does not answer here.
> If I downgrade to tomcat 9.0.29 it works without any problems.
>
> I started then wireshark and had a look into the traffic coming from the
> IIS.
>  From IIS is see a AJP13 connection with the following content in "Apache
> JServ Protocol v1.3" part in wireshark:
> ...
> Sec-Fetch-User: ?1
> token
> INTERNAL\user
> Negotiate
> ...
>
> as the token is here included the secret configuration is maybe correct.
> The token is here equal to the token define on IIS-tomcat-connector and
> the tomcat server.xml AJP definition.
> Tomcat is sending back a "0:RSP:SEND HEADERS:403 403"
>
> The IIS is doing authentication is is then just sending the user to
> tomcat.
>
> Regarding the documentation everything seems to be configured correctly,
> but it does not work.
> Could anyone help me here, please?
>
> --
> Thanks a lot
> Matthias
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 
_
Stephen Hames, Systems Architect & Release Manager
Singapore | +65 6403 5900
CloudPay 
-- 
_
Stephen Hames, Systems Architect & Release Manager
Singapore | +65 6403 5900
CloudPay 

-- 


This message may
contain confidential and privileged information. If it 
has been sent to you in
error, please reply to advise the sender of the 
error and then immediately
delete this message.

Re: Problem with tomcat connector in IIS using tomcat 9.0.31

[Martin Grigorov]

Hi Matthias,

Please read this discussion:
https://lists.apache.org/thread.html/r9f3a2ea48f2e76f7c092ea2dc4caec7d15c86f7773281ef6c8cdb817%40%3Cusers.tomcat.apache.org%3E

The problem and a workaround are explained here:
https://lists.apache.org/thread.html/r3720861ca584c0b6794cb8bfffafa18fa67b514f3df47ce7ea5329ef%40%3Cusers.tomcat.apache.org%3E

Regards,
Martin


On Wed, Mar 4, 2020 at 9:20 AM Matthias Fechner  wrote:

> Dear all,
>
> as tomcat version 9.0.31 has some security fixes included I tried to do
> an upgrade.
> On the IIS tomcat connector version 1.2.46 is installed.
>
> As secret I use a 32 character long alpha numeric string, I name it here
> token.
> In the workers.properties I tried to define it on the load balancer
> line:
> worker.loadbalancer.secret=token
>
> And/or on each node:
> worker.node1.secret=token
> ...
> worker.node2.secret=token
>
> For the tomcat configuration I defined in server.xml the following AJP
> connector:
>   address="::"
> port="8009"
> tomcatAuthentication="false"
> enableLookups="false"
> secret="token"
> redirectPort="8443" />
>
> But it does not work. It seems that tomcat does not answer here.
> If I downgrade to tomcat 9.0.29 it works without any problems.
>
> I started then wireshark and had a look into the traffic coming from the
> IIS.
>  From IIS is see a AJP13 connection with the following content in "Apache
> JServ Protocol v1.3" part in wireshark:
> ...
> Sec-Fetch-User: ?1
> token
> INTERNAL\user
> Negotiate
> ...
>
> as the token is here included the secret configuration is maybe correct.
> The token is here equal to the token define on IIS-tomcat-connector and
> the tomcat server.xml AJP definition.
> Tomcat is sending back a "0:RSP:SEND HEADERS:403 403"
>
> The IIS is doing authentication is is then just sending the user to
> tomcat.
>
> Regarding the documentation everything seems to be configured correctly,
> but it does not work.
> Could anyone help me here, please?
>
> --
> Thanks a lot
> Matthias
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Martin Grigorov]

Hi Johan,

On Mon, Mar 2, 2020 at 7:32 PM Johan Compagner 
wrote:

> And when you are at it, also mention there in big letters that they really
> should read the release notes... This tomcat will not work with all the
> major frameworks people use for quite some time...
>

If you still use Apache Wicket (and I bet you do! :-) ) I've tested it
successfully on 10.0.0-M1 for you:
https://twitter.com/mtgrigorov/status/1225359299570028546

But I agree that this information should be emphasized in Tomcat docs!
I'll update the website!

Martin


>
> Op ma 2 mrt. 2020 18:23 schreef Christopher Schultz <
> ch...@christopherschultz.net>:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > All,
> >
> > If you go to tomcat.apache.org right now, you'll see documentation and
> > downloads for Tomcat 10. In the news section, it's shown as 10.0.0-M1
> > so that might be an indication that it's not a "normal" release.
> >
> > Anyone going to the site and not reading the (current) top-item of
> > news might think that Tomcat 10 is the current best version to download.
> >
> > I propose the following:
> >
> > 1. Add a [beta] (or similar) badge to the [Tomcat 10] download and
> > [Tomcat 10.0] documentation links.
> >
> > 2. On the "which version" page, add a [beta] (or similar) badge to the
> > Tomcat 10 release
> >
> > 3. On the Tomcat 10 downloads page, in the summary section, add a very
> > prominent statement that says Tomcat 10 is in [beta] or similar. I
> > might even use a large font and/or red or some other
> > attention-grabbing text color.
> >
> > 4. Similar to [3] above, but on the Tomcat 10 documentation page
> > introduction.
> >
> > WDYT?
> >
> > - -chris
> > -BEGIN PGP SIGNATURE-
> > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> >
> > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5dQOkACgkQHPApP6U8
> > pFglHA//XKKCS260Hvx+gA5YshiPYOpKS7FOG/bDzef9Y+JqMpuFMrOt/7d2AG2/
> > X7GqQ57mJ+aew5p+nncXWV5yXd3fGyhPCeDsdF5pNc3K87dYs0MZCt/5nB9D2mJK
> > 3uoRQjQscwo2pBuozpBViw19HoeoEjQGWHWrs60LTckODDQj1IcT6zZUgckGkMaP
> > sPu1x+kra+5psKWtK91S6KOERoYQ13gNhIAIlEgCavLzwOoyz3El5/9iXne2rP/w
> > tePV+1e9r7ltF6WBJtA72xMAS1mXvK+bW1Wpm/5dMicpnRF04vaOUlZularWgbvO
> > 8p67YCJ3keaVtKcfDVHxSUVUUbjroWX9beoOnTDujw6zUapoKzibtU9EEyEOQXIW
> > C946ZhyPjS6I+liRHGQHKkQgBMUpHC+WGmasC5RW6+hySJCTjp6TGKlr5vuDk0th
> > OtcuHgzaOoqqVjYOZwArQi96c0l5/RW/6wxseunvK5n8TzP/l3F5jP627dUodsWV
> > B1qQfP3aePMGaTnRDuookTBoS1FLANc2Fc0m6hpTJmVkgcrYSFo4vmlljSGUCSkB
> > rUzY10W3rLu467ipcoFEzMGgVmM0cO29qk35JqPj0DtZa5BbFQTQa95iERxnRx45
> > izIC7Nz5+UUdjdcoMhIVMdq/oA1TC++MXpRMOoYlOpnOf7hT+yo=
> > =nLsr
> > -END PGP SIGNATURE-
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>