Re: IIS 10.0 as Tomcat reverse proxy does not send auth_type and remote_user AJP heder

2021-07-15 Thread tomcat/perl

Sorry, I haven't read the whole thread, but a basic question :
In the tomcat AJP Connector configuration, is "tomcatAuthentication" set to 
"no" ?
https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Common_Attributes

On 13.07.2021 17:35, Paolo Clerici wrote:

I don't see any ISAPI redirector set up there. I was expecting to see
something like the steps described here:
http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html

Yes, if I have not missed something, I think I have done everything
that is written in the document.
The only differences are that there are two sites "prod" and "test" so
the only differences for "test" are:
1) Dll folder: C:\Apache Software Foundation\Jakarta Isapi Redirector\test\bin
2) ISAPI filter name: "Jakarta Connector test" (not "tomcat")

isapi_redirect.properties file content:
extension_uri=/jakarta/isapi_redirect.dll
log_file=C:\Apache Software Foundation\Jakarta Isapi
Redirector\test\log\mod_jk.log
log_level=warn
worker_file=C:\Apache Software Foundation\Jakarta Isapi
Redirector\test\conf\workers.properties
worker_mount_file=C:\Apache Software Foundation\Jakarta Isapi
Redirector\test\conf\uriworkermap.properties

workers.properties file content:
worker.list=dgroupnex02,dgroupnex01
worker.dgroupnex02.type=ajp13
worker.dgroupnex02.host=10.1.2.93
worker.dgroupnex02.port=8009
worker.dgroupnex01.type=ajp13
worker.dgroupnex01.host=10.1.2.39
worker.dgroupnex01.port=8009

uriworkermap.properties file content:
/S2W/*=dgroupnex02
/s2wweb/*=dgroupnex01
/websat/*=dgroupnex02

I would like to tell you that ISAPI redirection of all virtual folders
works perfectly. The only thing that doesn't work is sending the
authorization type and user from IIS to Tomcat.
The only application that needs this functionality is "s2wweb".

Thanks,
Paolo









Il giorno mar 13 lug 2021 alle ore 14:44 Mark Thomas
 ha scritto:


On 13/07/2021 12:29, Paolo Clerici wrote:

Hi Mark,


How did you set up the s2wweb virtual directory?

Physical Path: C:\Apache Software Foundation\virtual\test\s2wweb
Physical Path Credential: blank
Physical Path Credential Logon Type: Clear Text
Virtual Path: /s2wweb
Pass-through authentication: / Connect As: / Path credentials:
Application user (pass-through authentication)


I don't see any ISAPI redirector set up there. I was expecting to see
something like the steps described here:

http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html

Mark




Thanks,
Paolo
Il giorno mar 13 lug 2021 alle ore 10:27 Mark Thomas
 ha scritto:


On 13/07/2021 08:49, Paolo Clerici wrote:

Hi Mark,


Are you connecting from a machine that isn't part of the Windows AD?

I have tried both from PCs connected to AD and from PCs not connected to AD.


Normally, I'd expect authentication to work without any password prompt.

If I connect from PC AD I am not asked for credentials (correct). If I
connect from a non-AD PC I am prompted for credentials (correctly).
The credential check is done correctly by IIS.


Are any other authentication mechanisms enabled?

For virtual directory "s2wweb" only "Windows Authentication" is
enabled ("Anonymous Authentication" is disabled). For site "test" is
enabled "Anonymous Authentication".


Are your two test machines (working and not working) connecting to the
same Tomcat instance (and on the same port)?

Yes.
Current IIS server needs to be migrated to a new IIS server. The
current server (Windows Server 2008 R2 with IIS 6.1) is connected to
the same Tomcat server (another Windows Server 2008 R2 with Tomcat
7.0) on the same port (8009).


Again, testing a similar setup locally works as expected. The
authenticated Windows user name is passed to Tomcat.

How did you set up the s2wweb virtual directory?

Mark

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



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




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



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




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



Re: Archive or package install

2021-06-18 Thread tomcat-lists
Hi Christopher,

On 18.06.21 20:54, Christopher Schultz wrote:
>> I would only stick to the distro-provided packages, if it is a small
>> (in other words not that important) application running in Tomcat. Just
>> for reference: With Ubuntu 18.04, you would end up
>> with 9.0.16 vs. 9.0.48 (Tomcat project) or 8.5.39 vs. 8.5.68 (Tomcat
>> project), which is about 2 years old software.

> The above statement is *very* misleading.
> 
> To understand why it's misleading, you have to understand the Debian "way" of 
> package-management. Ubuntu is Debian-derived and, although they have their 
> own package repositories, etc., they do
> inherit from upstream and do make some changes on their own separate from 
> upstream.

Thanks for picking that up, I was not clear enough by just referencing the 
security back ports in one sentence. It is right, that those distro packages 
get updates. My main point is, that due
to the update policy of Ubuntu (and Debian as well), not all changes and 
updates will get into the distro packages. This might be an issue, especially 
if IT organisation stick to a specific
distros version for a long time. This is not an issue with the distro policy or 
updates (never wanted to blame anyone from the Debian or Ubuntu team for that), 
but with the update policies of
the running org. I was focusing on *Ubuntu 18.04* (which was mentioned by 
Onno), for that change log [1] mentions Wed, 11 Sep 2019 as last update.

> All that junk at the end (-4~bpo9+1_all) indicates the various updates that 
> have been applied after the original 9.0.16. If you read the changelog[1] for 
> Buster, you'll see that it was last
> updated as recently as 2021-04-12 to apply fixes for CVE-2021-25122 and 
> CVE-2021-25329 (thanks, Emmanuel!). In fact, in Buster, you are getting 
> 9.0.31. I'll bet if you look at the Ubuntu
> changelog for your package, you'll find something similar.

You are right, if you manage your base system and keep it updated to recent 
version (not my experience though), this will be fine. However if you stick as 
long as possible to a distros version
(there is already a new Ubuntu LTS out for over a year, some time to update), 
you will have a gap to more recent Tomcat versions. Comparing Ubuntu 18.04 
Tomcat versions to current Ubuntu or
Debian versions, is not what was asked by the Onno. My experience is that some 
organisations try to stay on a specific distro version as long as possible.

> If you are getting 9.0.16 from your Ubuntu repository, I think you may be 
> getting "left behind" by something. The current Ubuntu package should 
> actually be a base version of 9.0.43. Older
> versions of Ubuntu have older base Tomcat versions.

Again current vs. Ubuntu 18.04 is a different story. My apologies, I should 
have been clearer in my first post.

[1] 
https://changelogs.ubuntu.com/changelogs/pool/universe/t/tomcat9/tomcat9_9.0.16-3ubuntu0.18.04.1/changelog

regards,
Thomas

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



Re: Archive or package install

2021-06-18 Thread tomcat-lists
Hi Onno,

On 18.06.21 07:07, Sugar Moose wrote:
> I am using Ansible role robertdebock.tomcat to install Tomcat. This role uses 
> archives from the Tomcat site to install Tomcat. I have always thought that 
> this is a fine approach but the customer has pointed out that a package 
> install is preferred because it makes installing security updates easier. 
> This customer uses Ubuntu 18.04 and the position of the InfraOps engineers is 
> that installing Tomcat from the official Ubuntu repository is always 
> preferred. 

Installing Tomcat directly from the archives is easy and straight forward, in 
my opinion it should be perfectly fine using upstream as source (you should at 
least verify the download).
Especially, if Tomcat plays a major role of the system (i.e. running some 
business critical applications), I would always stick to the version from 
Tomcat archives. You will end up with a more
recent version of Tomcat, as it is actively developed, those versions will 
contain all security fixes (directly from the team and without possible 
backporting of security fixes). If you use
CATALINA_HOME and CATALINA_BASE variables you can easily switch between 
different Tomcat versions, making it very easy to manage updates and possible 
necessary rollbacks.

I would only stick to the distro-provided packages, if it is a small (in other 
words not that important) application running in Tomcat. Just for reference: 
With Ubuntu 18.04, you would end up
with 9.0.16 vs. 9.0.48 (Tomcat project) or 8.5.39 vs. 8.5.68 (Tomcat project), 
which is about 2 years old software. For any errors you might get on distro 
packages, first hint would most
likely be to update to a recent Tomcat version. Even if security fixed are 
backported by the distro, you would end up with versions missing a lot of fixes 
and improvements.

> I don't know how exactly using apt packages makes life a lot easier when it 
> comes to security updates. I think it depends. If Ansible manages the version 
> it looks more or less the same to me. The Ansible role would have an var for 
> example tomcat_version and the value would determine the what version is on 
> the system. Updating Tomcat using Ansible would be same proces: update 
> tomcat_version var and provision the node. When Ansible is not managing the 
> version but is used for example only for the initial install using Ansible 
> package module it becomes a bit of a puzzle to figure out how this would 
> work. And also would have some drawbacks. Ansible is good at configuration 
> management and orchestration for example. Apt not really. 

Yes, Ansible is much more flexible for managing the configuration and 
deployment-parts. You will need something for that task, even if you use the 
distro-provided packages.

> What is the position / what are the thoughts on this in the Tomcat community? 
> On the Tomcat website I could find no information on package install. I don't 
> think a recommended installation approach is mentioned there. 

In short: If your application in Tomcat is important, use the Tomcat archive up 
to date versions, if not distro packages might be sufficient. This might be 
challenging, if Tomcat is managed by
the infrastructure team (from my experience, there is always a trend towards 
the distro packages, sometimes with the argument support by the distro). It 
might help, if managing the Tomcat can
be done by the applications support/devops team (however, that might depend on 
the organisation constraints).

hth,
Thomas

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



Re: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-26 Thread tomcat/perl

Addendum :

Maybe to debug this more efficiently, you could look at this issue from the 
opposite side :
Earlier in the thread of messages, you said this :

1. Did you upgrade anything recently (like Java VM)?
[YJ] To support Linux 8, only Postgres was upgraded from version 9.3 to 9.6.

Maybe when you did this, you also changed the driver which tomcat is using to communicate 
with Postgresql. And maybe the problem lies in that driver.
I mean that the driver is the piece of code which creates connections (using sockets) with 
Postgresql. And usually, that works and you have a number of ESTABLISHED connections 
(which are visible in the netstat output).
But what if, occasionally, the connection doesn't work, and the driver is not very clean 
in handling this failing socket ?


Or maybe the issue is in the code which uses these connections ?
Have a look at this :
https://stackoverflow.com/questions/2225221/closing-database-connections-in-java/2225275#2225275



On 26.05.2021 11:12, André Warnier (tomcat/perl) wrote:
Maybe I am missing something, but at first sight it looks like lsof, inside the container, 
can also not get more information about these "sock" things.


I am running out of ideas.
If you search in Google for precisely this :

lsof "sock" and "protocol : TCP"

there are a lot of links which discuss similar issues, and this over many years.
(So it is not either a unique or a recent issue).

They all seem to boil down to this : some *application* is opening sockets, but then not 
really using them (and not closing them).


In your case, that probably means one of the webapps running under tomcat.

It seems quite unlikely that this would be tomcat itself, because if that was the case, 
this tomcat users list would probably be swamped with requests such as yours; which it isn't.
It is worth noting also, that among all these messages found in Google, I have not so far 
seen a single one which provides another explanation for those "sock" things.


In your case, the problem is going to be in finding out *which* webapp does that, unless 
there are not many, and you can turn them off one-by-one selectively.
(The difficulty is in part due to the fact that, to the OS, the whole of the JVM, tomcat 
and all the webapps look like one single process; and to lsof also).


Maybe there is some type of logging available in tomcat, that would help finding out which 
application is creating sockets, and then never using or destroying them.

But my personal competences do not run that far, so maybe someone else can help 
you here.


On 26.05.2021 00:03, Yeggy Javadi wrote:

Hi,
Below is the nsenter output:

# ps -ef | grep tomcat
root  165217   1  1 10:22 ?    00:05:33 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server -Xms1800m 
-Xmx8192m -XX:MaxMetaspaceSize=1800m -Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Dignore.endorsed.dirs= 
-classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar 
-Dcatalina.base=/usr/local/apache-tomcat -Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp org.apache.catalina.startup.Bootstrap start

root  167329  167268  0 18:00 pts/1    00:00:00 grep --color=auto tomcat

# nsenter -t 165217 --net lsof -n -p 165217 |less
COMMAND    PID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
java    165217 root  cwd   DIR    8,2 4096   157664 
/usr/local/freestor/bin

java    165217 root  rtd   DIR    8,3 4096    2 /
java    165217 root  txt   REG    8,2 8712 8913 
/usr/local/jdk/jre1.8.0_271/bin/java
java    165217 root  mem   REG    8,2   113371   160881 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar 

java    165217 root  mem   REG    8,2   147874   160802 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar
java    165217 root  mem   REG    8,2   391515   160836 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar
java    165217 root  mem   REG    8,2   868615   160813 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar
java    165217 root  mem   REG    8,2 9711   160792 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar
java    165217 root  mem   REG    8,2   196573   160819 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar 

java    165217 root  mem   REG    8,2    97173   160843 
/usr/local/a

Re: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-26 Thread tomcat/perl
Maybe I am missing something, but at first sight it looks like lsof, inside the container, 
can also not get more information about these "sock" things.


I am running out of ideas.
If you search in Google for precisely this :

lsof "sock" and "protocol : TCP"

there are a lot of links which discuss similar issues, and this over many years.
(So it is not either a unique or a recent issue).

They all seem to boil down to this : some *application* is opening sockets, but then not 
really using them (and not closing them).


In your case, that probably means one of the webapps running under tomcat.

It seems quite unlikely that this would be tomcat itself, because if that was the case, 
this tomcat users list would probably be swamped with requests such as yours; which it isn't.
It is worth noting also, that among all these messages found in Google, I have not so far 
seen a single one which provides another explanation for those "sock" things.


In your case, the problem is going to be in finding out *which* webapp does that, unless 
there are not many, and you can turn them off one-by-one selectively.
(The difficulty is in part due to the fact that, to the OS, the whole of the JVM, tomcat 
and all the webapps look like one single process; and to lsof also).


Maybe there is some type of logging available in tomcat, that would help finding out which 
application is creating sockets, and then never using or destroying them.

But my personal competences do not run that far, so maybe someone else can help 
you here.


On 26.05.2021 00:03, Yeggy Javadi wrote:

Hi,
Below is the nsenter output:

# ps -ef | grep tomcat
root  165217   1  1 10:22 ?00:05:33 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server 
-Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar
 -Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root  167329  167268  0 18:00 pts/100:00:00 grep --color=auto tomcat

# nsenter -t 165217 --net lsof -n -p 165217 |less
COMMANDPID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
java165217 root  cwd   DIR8,2 4096   157664 
/usr/local/freestor/bin
java165217 root  rtd   DIR8,3 40962 /
java165217 root  txt   REG8,2 8712 8913 
/usr/local/jdk/jre1.8.0_271/bin/java
java165217 root  mem   REG8,2   113371   160881 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
java165217 root  mem   REG8,2   147874   160802 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar
java165217 root  mem   REG8,2   391515   160836 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar
java165217 root  mem   REG8,2   868615   160813 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar
java165217 root  mem   REG8,2 9711   160792 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar
java165217 root  mem   REG8,2   196573   160819 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar
java165217 root  mem   REG8,297173   160843 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-misc-4.10.4.jar
java165217 root  mem   REG8,210074   160872 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-ext-1.11.jar
java165217 root  mem   REG8,262983   160861 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activation-1.1.jar
java165217 root  mem   REG8,2   371668   160812 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-security-core-3.2.9.RELEASE.jar
java165217 root  mem   REG8,2   645914   160754 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-entitymanager-4.3.5.Final.jar
java165217 root  mem   REG8,2   427030   160753 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-envers-4.3.5.Final.jar
java165217 root  mem   REG8,2   256468   160829 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/barcode4j-2.0.jar
java16521

Re: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-25 Thread tomcat/perl

Hi.
The point is to try to figure out what these thousands of apparently "TCPv6" sockets 
belonging to the tomcat process actually are, so that we can maybe begin to look at where 
they may be coming from.
The trouble is, the lsof output so far did not really tell us what these "sock" things 
might be.


But there may be a clue here :
https://serverfault.com/questions/1000338/in-lsof-output-what-are-those-sock-lines
(about when things run in a container).
Is that your case ?
And if so, could you run the lsof command in the container, as they suggest ?

And the point of forcing a tomcat/JVM GC was this :
When you restart tomcat (actually the JVM which runs tomcat), the OS will clean up *all* 
the file descriptors belonging to that process, including the "legitimate" ones shown by 
netstat, and the "unknown" ones shown in addition by lsof.
Doing a GC, without stopping the JVM, would clean up *only* such sockets/fd that are held 
by objects which are discarded, but still sit on the heap awaiting a GC to really destroy 
them.  If your heap is very large, it may otherwise take a long while before such a GC 
happens, and such sockets could accumulate.
One way to trigger a GC is through JMX, but it takes a bit of additional setup to make 
that work. That's why I was asking if you had some method to do that.

(see : https://code.google.com/archive/p/jmxsh/)
But let's look at the lsof part first.



On 24.05.2021 16:09, Yeggy Javadi wrote:

Hi,
I restarted tomcat so PID has changed to 143152; I do not know how to trigger 
tomcat GC, I just restart it to reset the lsof to 0.
Please see outputs below:

# ps -ef | grep tomcat
root  143152   1  0 May22 ?00:26:44 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server 
-Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar
 -Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root  153962  153912  0 10:00 pts/100:00:00 grep --color=auto tomcat

# lsof -p 143152 | wc -l
41043

# lsof -p 143152 | grep "protocol: TCPv6"| wc -l
40487

# netstat -p -a -n --inet6 | grep 143152
tcp6   0  0 :::8443 :::*LISTEN  
143152/java
tcp6   0  0 :::443  :::*LISTEN  
143152/java
tcp6   0  0 127.0.0.1:8005  :::*LISTEN  
143152/java
tcp6   0  0 :::1099 :::*LISTEN  
143152/java
tcp6   0  0 :::80   :::*LISTEN  
143152/java
tcp6   0  0 :::36081:::*LISTEN  
143152/java
tcp6   0  0 10.4.3.55:60736 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60732 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60728 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:8010.197.255.10:55446 ESTABLISHED 
143152/java
tcp6   1  0 10.4.3.55:55958 10.4.3.55:11576 CLOSE_WAIT  
143152/java
tcp6   0  0 10.4.3.55:53682 172.22.21.48:443ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48622 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60748 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   1  0 10.4.3.55:55956 10.4.3.55:11576 CLOSE_WAIT  
143152/java
tcp6   0  0 10.4.3.55:40574 172.22.21.47:443ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48620 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:53782 172.22.21.48:443ESTABLISHED 
143152/java
tcp6   0  1 10.4.3.55:49808 10.12.3.78:443  SYN_SENT
143152/java
tcp6   0  0 10.4.3.55:60730 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60750 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60742 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60746 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48624 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60734 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   

Re: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-23 Thread tomcat/perl

Hi.

I have no idea what lines like this are :

java130244 root   78u sock0,9  0t0 12154374 
protocol: TCPv6


There are obviously too many of them, for them to match with the sockets listed 
by netstat.

The ones which in the lsof output, have "TYPE" set to "IPv6" seem to correspond to the 
ones marked as "LISTEN" in the netstat output.

But the ones with TYPE="sock" and NAME="protocol: TCPv6" are a mystery to me.

Could you redo a netstat as follows :
# netstat -p -a -n --inet6 | grep 130244

and can you also try this form of lsof :
# lsof -a -p 130244 -T s -i6

And finally (after copying the result of the above) : do you know how to trigger a GC 
(Garbage Collection) in your tomcat JVM ?

(the point is to see if when a GC happens, these things disappear).


On 22.05.2021 18:03, Yeggy Javadi wrote:

Here it is:

# netstat -p -a  --tcp | grep 130244
tcp6   0  0 [::]:pcsync-https   [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:https  [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:37537  [::]:*  LISTEN  
130244/java
tcp6   0  0 localhost.localdoma:mxi [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:8009   [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:rmiregistry[::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:http   [::]:*  LISTEN  
130244/java
tcp6  86  0 Yeggy-F8-FMSVA:39680172.22.22.192:https CLOSE_WAIT  
130244/java
tcp6   0  1 Yeggy-F8-FMSVA:5361810.12.3.78:httpsSYN_SENT
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54772Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:42664 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54782Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54766Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:42662 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54778Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54788Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54770Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54790Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54776Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54786Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54780Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:45736 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54768Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54784Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:42660 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  1 Yeggy-F8-FMSVA:4292210.12.3.77:httpsSYN_SENT
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:35794172.22.22.192:https ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54774Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:45734 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:41016 localhost.localdo:vrace ESTABLISHED 
130244/java


# lsof -p 130244
COMMANDPID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
java130244 root  cwd   DIR8,2 4096   157664 
/usr/local/freestor/bin
java130244 root  rtd   DIR8,3 40962 /
java130244 root  txt   REG8,2 8712 8913 
/usr/local/jdk/jre1.8.0_271/bin/java
java130244 root  mem   REG8,2   498864 9007 
/usr/local/jdk/jre1.8.0_271/lib/amd64/libfontmanager.so
java130244 root  mem   REG8,239176 9006 
/usr/local/jdk/jre1.8.0_271/lib/amd64/libawt_headless.so
java130244 root  mem   REG8,2   759184 8996 
/usr/local/jdk/jre1.8.0_271/lib/amd64/libawt.so
java130244 root  mem   REG8,2  3559360 9139 
/usr/local/jdk/jre1.8.0_271/lib/resources.jar
java130244 root  mem   REG8,299680   133076 
/usr/lib64/libgcc_s-8-20191121.so.1
java130244 root  mem   REG8,2  3135658 9133 
/usr/local/jdk/jre1.8.0_271/lib/charsets.jar
java130244 root  mem   REG8,2   283368 8980 
/usr/local/jdk/jre1.8.0_271/lib/amd64/libsunec.so
java130244 root  mem   REG   

Re: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-22 Thread tomcat/perl

Mmm. Nothing very special in that netstat output.
The sockets seen there look quite normal for tomcat, and there are not a lot.
What about the IPv4 sockets ? (remove the -6 in your netstat command)

Looks like lsof is counting things which are not IPv6 TCP sockets belonging to the tomcat 
JVM process.

Where is the difference between the lsof count (19948) and the netstat count 
(25) ?
(genuine question, I'm puzzled too)

Can you give an example of the "lsof -p 130244" output lines ?
(not all 19948 please, but enough to see some variety)

On 21.05.2021 16:11, Yeggy Javadi wrote:

Hi,
Here its is:
# lsof -p 130244 | grep "protocol: TCPv6"| wc -l
19948

# netstat -p -a -6 --tcp | grep 130244
tcp6   0  0 [::]:pcsync-https   [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:https  [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:37537  [::]:*  LISTEN  
130244/java
tcp6   0  0 localhost.localdoma:mxi [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:8009   [::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:rmiregistry[::]:*  LISTEN  
130244/java
tcp6   0  0 [::]:http   [::]:*  LISTEN  
130244/java
tcp6  86  0 Yeggy-F8-FMSVA:39680172.22.22.192:https CLOSE_WAIT  
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54772Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:42664 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54782Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54766Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:42662 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54778Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:46966 localhost.localdo:11753 ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54788Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54770Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:http 10.197.255.10:64799 ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54790Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54776Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54786Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54780Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:45736 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54768Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54784Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:42660 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:54774Yeggy-F8-FMSVA:vraceESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:45734 localhost.loca:postgres ESTABLISHED 
130244/java
tcp6   0  0 Yeggy-F8-FMSVA:http 10.197.255.10:64798 ESTABLISHED 
130244/java
tcp6   0  0 localhost.localdo:41016 localhost.localdo:vrace ESTABLISHED 
130244/java
Thanks
-Original Message-
From: Noelette Stout 
Sent: Friday, May 21, 2021 8:28 AM
To: Tomcat Users List 
Subject: Re: apache-tomcat-8.5.59 too many open files on Linux 8

ss has all the same options as netstat

On Fri, May 21, 2021 at 3:51 AM André Warnier (tomcat/perl) 
wrote:


Soyrry to top-post, but it's getting cluttered down there..

The next thing that you may want to do :

   > netstat -p -a -6 --tcp

That is an alternative list of sockets, which also shows the "tcp state"
of the sockets.
To get only the ones of the tomcat JVM PID, filter with grep based of
the last column.
The type of thing you are looking for is the column which should show
"LISTEN", or "ESTABLISHED" or "CLOSE_WAIT" etc..

The options above :
-p : show PID and program
-a : show all sockets states
-6 : only inet v6
--tcp : only TCP sockets

"netstat" may not be on your system by default, and you may need to
install it.
An alternative is "ss", but I don't know the options.


On 21.05.2021 02:14, Yeggy Javadi wrote:

Hi,
Yes; that is what I get and as you can see among 8028 open files,
7474

are for TCPv6 sockets:

java130244 root 7805u sock0,9  0t0 12294251

protocol: TCPv6


# ps -ef | grep tomcat
root  130244   1  1 11:01 ?00:06:20

/usr/local/jre/bin/java
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.
properties
-Djava.util.logging.manager=org.apac

Re: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-21 Thread tomcat/perl

Soyrry to top-post, but it's getting cluttered down there..

The next thing that you may want to do :

 > netstat -p -a -6 --tcp

That is an alternative list of sockets, which also shows the "tcp state" of the 
sockets.
To get only the ones of the tomcat JVM PID, filter with grep based of the last 
column.
The type of thing you are looking for is the column which should show "LISTEN", or 
"ESTABLISHED" or "CLOSE_WAIT" etc..


The options above :
-p : show PID and program
-a : show all sockets states
-6 : only inet v6
--tcp : only TCP sockets

"netstat" may not be on your system by default, and you may need to install it.
An alternative is "ss", but I don't know the options.


On 21.05.2021 02:14, Yeggy Javadi wrote:

Hi,
Yes; that is what I get and as you can see among 8028 open files, 7474 are for 
TCPv6 sockets:
java130244 root 7805u sock    0,9  0t0 12294251 
protocol: TCPv6

# ps -ef | grep tomcat
root  130244   1  1 11:01 ?00:06:20 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server 
-Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar
 -Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root      132566  132492  0 20:10 pts/100:00:00 grep --color=auto tomcat

#lsof -p 130244 | wc -l
8028

#lsof -p 130244 | grep "protocol: TCPv6"| wc -l
7474

Thanks

-Original Message-
From: André Warnier (tomcat/perl) 
Sent: Thursday, May 20, 2021 4:19 PM
To: users@tomcat.apache.org
Subject: Re: apache-tomcat-8.5.59 too many open files on Linux 8

Hi.
According to the list below, you have 2 java (JVM) processes running on your 
system.
One (PID = 130244) is the JVM which runs tomcat.  This is visible when you look 
at the whole command-line.

The other (PID = 130516) runs ElasticSearch, which I believe is not relevant 
here.

So you should run lsof with the "-p 130244" option, to show only the files 
opened by the tomcat JVM.
To show the current Tomcat JVM PID, do e.g. : ps -ef | grep "apache-tomcat"
(or anything else unique in that line)


On 20.05.2021 21:00, Yeggy Javadi wrote:

Hi Chris,
Please indicate how to show lsof or netstat to *just the JVM* process.

Below is the list of running processes on my server:
UID  PIDPPID  C STIME TTY  TIME CMD
root   1   0  0 May07 ?00:00:14 /usr/lib/systemd/systemd 
--switched-root --system --deserialize 17
root   2   0  0 May07 ?00:00:00 [kthreadd]
root   3   2  0 May07 ?00:00:00 [rcu_gp]
root   4   2  0 May07 ?00:00:00 [rcu_par_gp]
root   6   2  0 May07 ?00:00:00 [kworker/0:0H-kblockd]
root   8   2  0 May07 ?00:00:00 [mm_percpu_wq]
root   9   2  0 May07 ?00:00:00 [ksoftirqd/0]
root  10   2  0 May07 ?00:02:18 [rcu_sched]
root  11   2  0 May07 ?00:00:00 [migration/0]
root  12   2  0 May07 ?00:00:00 [watchdog/0]
root  13   2  0 May07 ?00:00:00 [cpuhp/0]
root  14   2  0 May07 ?00:00:00 [cpuhp/1]
root  15   2  0 May07 ?00:00:00 [watchdog/1]
root  16   2  0 May07 ?00:00:00 [migration/1]
root  17   2  0 May07 ?00:00:00 [ksoftirqd/1]
root  19   2  0 May07 ?00:00:00 [kworker/1:0H-kblockd]
root  20   2  0 May07 ?00:00:00 [cpuhp/2]
root  21   2  0 May07 ?00:00:00 [watchdog/2]
root  22   2  0 May07 ?00:00:00 [migration/2]
root  23   2  0 May07 ?00:00:00 [ksoftirqd/2]
root  25   2  0 May07 ?00:00:00 [kworker/2:0H-kblockd]
root  26   2  0 May07 ?00:00:00 [cpuhp/3]
root  27   2  0 May07 ?00:00:00 [watchdog/3]
root  28   2  0 May07 ?00:00:00 [migration/3]
root  29   2  0 May07 ?00:00:00 [ksoftirqd/3]
root  31   2  0 May07 ?00:00:00 [kworker/3:0H-kblockd]
root  32   2  0 May07 ?00:00:00 [cpuhp/4]
root  33   2  0 May07 ?00:00:00 [watchdog/4]
root  34   2  0 May07 ?00:00:00 [migration/4]
root  35   2  0 May07 ?00:00:00 [ksoftirqd/4]
root  37   2  0 May07 ?00:00:00 [kworker/4:0H-kblockd]
ro

Re: apache-tomcat-8.5.59 too many open files on Linux 8

2021-05-20 Thread tomcat/perl

Hi.
According to the list below, you have 2 java (JVM) processes running on your 
system.
One (PID = 130244) is the JVM which runs tomcat.  This is visible when you look at the 
whole command-line.


The other (PID = 130516) runs ElasticSearch, which I believe is not relevant 
here.

So you should run lsof with the "-p 130244" option, to show only the files opened by the 
tomcat JVM.

To show the current Tomcat JVM PID, do e.g. : ps -ef | grep "apache-tomcat"
(or anything else unique in that line)


On 20.05.2021 21:00, Yeggy Javadi wrote:

Hi Chris,
Please indicate how to show lsof or netstat to *just the JVM* process.

Below is the list of running processes on my server:
UID  PIDPPID  C STIME TTY  TIME CMD
root   1   0  0 May07 ?00:00:14 /usr/lib/systemd/systemd 
--switched-root --system --deserialize 17
root   2   0  0 May07 ?00:00:00 [kthreadd]
root   3   2  0 May07 ?00:00:00 [rcu_gp]
root   4   2  0 May07 ?00:00:00 [rcu_par_gp]
root   6   2  0 May07 ?00:00:00 [kworker/0:0H-kblockd]
root   8   2  0 May07 ?00:00:00 [mm_percpu_wq]
root   9   2  0 May07 ?00:00:00 [ksoftirqd/0]
root  10   2  0 May07 ?00:02:18 [rcu_sched]
root  11   2  0 May07 ?00:00:00 [migration/0]
root  12   2  0 May07 ?00:00:00 [watchdog/0]
root  13   2  0 May07 ?00:00:00 [cpuhp/0]
root  14   2  0 May07 ?00:00:00 [cpuhp/1]
root  15   2  0 May07 ?00:00:00 [watchdog/1]
root  16   2  0 May07 ?00:00:00 [migration/1]
root  17   2  0 May07 ?00:00:00 [ksoftirqd/1]
root  19   2  0 May07 ?00:00:00 [kworker/1:0H-kblockd]
root  20   2  0 May07 ?00:00:00 [cpuhp/2]
root  21   2  0 May07 ?00:00:00 [watchdog/2]
root  22   2  0 May07 ?00:00:00 [migration/2]
root  23   2  0 May07 ?00:00:00 [ksoftirqd/2]
root  25   2  0 May07 ?00:00:00 [kworker/2:0H-kblockd]
root  26   2  0 May07 ?00:00:00 [cpuhp/3]
root  27   2  0 May07 ?00:00:00 [watchdog/3]
root  28   2  0 May07 ?00:00:00 [migration/3]
root  29   2  0 May07 ?00:00:00 [ksoftirqd/3]
root  31   2  0 May07 ?00:00:00 [kworker/3:0H-kblockd]
root  32   2  0 May07 ?00:00:00 [cpuhp/4]
root  33   2  0 May07 ?00:00:00 [watchdog/4]
root  34   2  0 May07 ?00:00:00 [migration/4]
root  35   2  0 May07 ?00:00:00 [ksoftirqd/4]
root  37   2  0 May07 ?00:00:00 [kworker/4:0H-kblockd]
root  38   2  0 May07 ?00:00:00 [cpuhp/5]
root  39   2  0 May07 ?00:00:00 [watchdog/5]
root  40   2  0 May07 ?00:00:00 [migration/5]
root  41   2  0 May07 ?00:00:00 [ksoftirqd/5]
root  43   2  0 May07 ?00:00:00 [kworker/5:0H-kblockd]
root  44   2  0 May07 ?00:00:00 [cpuhp/6]
root  45   2  0 May07 ?00:00:00 [watchdog/6]
root  46   2  0 May07 ?00:00:00 [migration/6]
root  47   2  0 May07 ?00:00:00 [ksoftirqd/6]
root  49   2  0 May07 ?00:00:00 [kworker/6:0H-kblockd]
root  50   2  0 May07 ?00:00:00 [cpuhp/7]
root  51   2  0 May07 ?00:00:00 [watchdog/7]
root  52   2  0 May07 ?00:00:00 [migration/7]
root  53   2  0 May07 ?00:00:00 [ksoftirqd/7]
root  55   2  0 May07 ?00:00:00 [kworker/7:0H-kblockd]
root  57   2  0 May07 ?00:00:00 [kdevtmpfs]
root  58   2  0 May07 ?00:00:00 [netns]
root  59   2  0 May07 ?00:00:00 [kauditd]
root  62   2  0 May07 ?00:00:00 [khungtaskd]
root  63   2  0 May07 ?00:00:00 [oom_reaper]
root  64   2  0 May07 ?00:00:00 [writeback]
root  65   2  0 May07 ?00:00:00 [kcompactd0]
root  66   2  0 May07 ?00:00:00 [ksmd]
root  67   2  0 May07 ?00:00:02 [khugepaged]
root  68   2  0 May07 ?00:00:00 [crypto]
root  69   2  0 May07 ?00:00:00 [kintegrityd]
root  70   2  0 May07 ?00:00:00 [kblockd]
root  71   2  0 May07 ?00:00:00 [tpm_dev_wq]
root  72   2  0 May07 ?00:00:00 [md]
root  73   2  0 May07 ?00:00:00 [edac-poller]
root  74   2  0 May07 ?00:00:00 [watchdogd]
root  92   2  0 May07 ?00:00:00 [kswapd0]
root 188   2  0 May07 ?00:0

Re: [OT] programming style or mental process ?

2021-04-07 Thread tomcat/perl

On 06.04.2021 20:06, gustavo.avitab...@unina.it wrote:

To nitpick, in Spanish one would rather say "cafe frio".


... and, in Italian, "caffè freddo",
but we Italians love coffee, and we have much phantasy, so try also:
"granita di caffè", "caffè gelato", "caffè col ghiaccio", "il caffè s'è fatto 
freddo", ...


Not so you'd think that Italians are the only ones with imagination when it comes to 
coffee, Spanish people also call this "granizado de cafe" (or "cafe granizado") or "cafe 
del tiempo". And that's only for the basic cold type, because there are many subtypes each 
with it's own name, with and without different types of liquor (flambé or not), short, 
medium, large or "americano" (== like water), real coffee or powder, decaffeinated or not, 
with or without (hot or cold) milk, in different types of recipients.


And not that some people would think that this is now all totally [OT], I would remind 
everyone of the definite historical and cultural connections between Tomcat, Java, 
programming and coffee (and Jakarta). (And dutch people. Where are they in this discussion 
by the way ? (but they have only one type of coffee I think)).



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



Re: What exactly does the AJP connector on 8009 do?

2021-04-06 Thread tomcat/perl

On 06.04.2021 00:45, James H. H. Lampert wrote:

On 4/5/21 1:22 PM, Christopher Schultz wrote:
If you are not running a reverse-proxy in front of Tomcat, then it does absolutely 
nothing for you.


If you *are* running a reverse-proxy in front of Tomcat, then it *may* do something for 
you, depending upon what software you are using and what its configuration is.


Thanks.

Hmm. We have *something* on one of our cloud servers, that has Tomcat sitting behind httpd 
(on the same box), and we have load balancing (through a couple of AWS Beanstalks) on our 
cloud-based product, but I don't know if the AJP port is involved in any of that.




I don't know about AWS Beanstalks, but for Apache httpd, there are some tell-tale 
configuration directives in the Apache httpd configuration files, which - if present - 
will tell you if Apache httpd is communicating with the back-end tomcat using the AJP 
protocol (and hence tomcat's AJP Connector).

Look for either of :
- ProxyPass instructions mentioning "AJP:"
- SetHandler jakarta-servlet
- JkMount
(case does generally not matter)

(Note that under Linux(es), your Apache httpd config files may be spread in small chunks 
all over the place, generally in locations such as "/etc/apache2/*" or "/etc/httpd/*") (*)

 Relevant documentation is available here :
1) http://tomcat.apache.org/connectors-doc/
2) http://tomcat.apache.org/connectors-doc/reference/apache.html
3) http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypass
4) (more complicated cases) 
http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewriterule

Also, if Apache httpd uses AJP to communicate with tomcat, then either one of these Apache 
httpd add-on modules will be loaded and configured :

- mod_jk
- mod_proxy_ajp
To find out which modules are loaded by Apache httpd, use the following command 
:
# apache2ctl -M
(Note that the mere fact that a module is loaded, does not necessarily mean that it is 
being *used*; but if neither of them is loaded, then you can be pretty sure that Apache 
httpd is NOT using AJP)


Shortcut :
- comment-out the AJP Connector in the tomcat configuration
- restart tomcat
- and wait for desperate support calls



(*) This is not a critic : it is very flexible that way; it's just a bit more work to 
search for the right files.


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



Re: [OT] programming style or mental process ?

2021-04-06 Thread tomcat/perl

On 05.04.2021 14:37, Christopher Schultz wrote:
Or, more literarily, given that the syntax of most (all?) programming languages is based 
on English (if, then, else, new, for, while, until, exit, continue, etc.), we (*) do 
normally ask "is your coffee cold ?" and not "is cold your coffee ?".


On the other hand, in English, coffee which is not hot is called "cold coffee" but in e.g. 
Spanish, it's "coffee cold".


To nitpick, in Spanish one would rather say "cafe frio".
But that's a bit beside the point since - as mentioned above - most currently fashionable 
programming languages are based on English.

Nevertheless, just for the sake of it, and in some imaginary situation
in which the Java syntax would be based on Spanish, one would probably have 
this :

  si (nada == requerimiento.obtengaCodificaciónCarácteros()) entonces {

  } sino {

  }

as opposed to

   si (requerimiento.obtengaCodificaciónCarácteros() == nada) entonces {

  } sino {

  }

.. which makes it even more striking that the first form deviates from the human language, 
because "nothing" cannot really be equal to anything, and thus the first form should 
always evaluate to false. (*)


(Which would also lead to more concise Java programs, because if you already know the 
answer, then you don't even need to make the test in the first place.)


On the other hand, this provides an interesting insight into English-speaking people's 
thought processes, for example as to the expression "nothing matches a good coffee in the 
morning", which is undoubtedly evaluated as true by many, although logically it cannot be.


:-)


(*) actually, this appears to be false : in Java, (null == null) is true.
See here for an in-depth discussion : 
https://stackoverflow.com/questions/2707322/what-is-null-in-java


P.S.
If anyone is interested about how it would be to write programs based on a Latin-inspired 
programming language, I recommend this :

https://metacpan.org/pod/distribution/Lingua-Romana-Perligata/lib/Lingua/Romana/Perligata.pm
(in which language it would be very difficult to confuse "==" and "=")

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



Re: [OT] programming style or mental process ?

2021-04-04 Thread tomcat/perl

On 05.04.2021 00:21, Zala Pierre GOUPIL wrote:


In your case, with a function call, this wouldn't make a difference
"if(request.getCharacterEncoding() = null)" would be illegal syntax as
well, but "if(someObject = null)" is perfectly legal, but doesn't
express the author's intent clearly: Is it a smart person who's taking a
shortcut, or a newbie using the wrong operator?



Let the seasoned programmer who's never made that same mistake throw the
first stone.




I think I never did that mistake. Or at least, I didn't realize it.



J'ai jamais tué d'chats
Ou alors y'a longtemps
Ou bien j'ai oublié
Ou ils sentaient pas bon
(Jacques Brel - Ces gens-là)

Couldn't resist.


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



Re: [OT] programming style or mental process ?

2021-04-04 Thread tomcat/perl

On 04.04.2021 12:57, Olaf Kock wrote:

Hi André

On 04.04.21 12:23, André Warnier (tomcat/perl) wrote:


   if (null == request.getCharacterEncoding()) {

as opposed to

   if (request.getCharacterEncoding() == null) {


So why do (some) people write it the other way ?
Is it purely a question of individual programming style ?
Is there some (temporary ?) fashion aspect involved ?
Do the people who write this either way really think in a different way ?
Or is there really something "technical" behind this, which makes one
or the other way be slightly more efficient (whether to compile, or
optimise, or run) ?

(*) excepting Yoda of course


I can't say I'm always writing Yoda style, but if I stretch my memory,
then the rationale behind this style of comparisons is to have a
constant on the left side, so that you get a compiler error in case
you're using = instead of ==.


I like that explanation, in the sense that it provides a programming rationale for using 
the first form (and not only in Java), even if it feels intuitively un-natural.

So it's apparently not only fashion or Yoda fandom.
Thanks.



In your case, with a function call, this wouldn't make a difference
"if(request.getCharacterEncoding() = null)" would be illegal syntax as
well, but "if(someObject = null)" is perfectly legal, but doesn't
express the author's intent clearly: Is it a smart person who's taking a
shortcut, or a newbie using the wrong operator?



Let the seasoned programmer who's never made that same mistake throw the first 
stone.


Of course, the style doesn't really help people new to the language, as
they first need to understand that this is something that they might
want to apply to their code. And today, with so many IDE warnings being
flagged while typing, it might be outdated, though it still clearly
expresses the intent to have a real comparison and not an assignment here.

And I agree with the other answer posted already: It makes a lot more
sense in C++ with all the implicit boolean conversions and habits of
outsmarting the code's maintainers with clever expressions.



+1 to that too.


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



[OT] programming style or mental process ?

2021-04-04 Thread tomcat/perl

Hi.
I have a question which may be totally off-topic for this list, but this has been puzzling 
me for a while and I figure that someone here may be able to provide some clue as to the 
answer, or at least some interesting ponts of view.


In various places (including on this list), I have seen multiple occurrences of a certain 
way to write a test, namely :


  if (null == request.getCharacterEncoding()) {

as opposed to

  if (request.getCharacterEncoding() == null) {

Granted, the two are equivalent in the end.
But it would seem to me, maybe naively, that the second form better corresponds to some 
"semantic logic", by which one wants to know if a certain a-priori unknown piece of data 
(here the value obtained by retrieving the character encoding of the current request) is 
defined (not null) or not (null).


Said another way : we don't want to know if "null" is equal to anything; we want to know 
if request.getCharacterEncoding() is null or not.


Or in yet another way : the focus (or the "subject" of the test) here is on 
"request.getCharacterEncoding()" (which we don't know), and not on "null" (which we know 
already).


Or, more literarily, given that the syntax of most (all?) programming languages is based 
on English (if, then, else, new, for, while, until, exit, continue, etc.), we (*) do 
normally ask "is your coffee cold ?" and not "is cold your coffee ?".



So why do (some) people write it the other way ?
Is it purely a question of individual programming style ?
Is there some (temporary ?) fashion aspect involved ?
Do the people who write this either way really think in a different way ?
Or is there really something "technical" behind this, which makes one or the other way be 
slightly more efficient (whether to compile, or optimise, or run) ?


(*) excepting Yoda of course


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



Re: [OT] Working with SAML

2021-03-17 Thread tomcat/perl

On 17.03.2021 17:49, Christopher Schultz wrote:

André,

On 3/16/21 18:21, André Warnier (tomcat/perl) wrote:

Alternatively, see this : 
https://wiki.shibboleth.net/confluence/display/SP3/JavaHowTo


Thanks for mentioning this. I looked at Shibboleth.

Their web site says "version 3 is deprecated" and "version 4 is undocumented".


We've been using versions 2 and 3 without problems. I don't know what version 4 brings, 
that is not in the others but nevertheless helpful.


We've set up one (our own) IdP (the SAML "identity provider", where the clients really 
login), and several SP (Service Provider), which interact with our own IdP or with other 
people's IdP's (of various brands/makes/types).

It's all a bit of work to set up, but once set up it hasn't given us any more 
hassle.
The documentation for versions 2 and 3 is very extensive, and quite complex, which I 
believe is kind of unavoidable considering that SAML itself is one of these things 
designed by a committee.


(We also have our own summarised installation and setup documentation, so if you want any 
tips, just ask)




:(

That's not exactly encouraging.

Thanks,
-chris


On 16.03.2021 21:18, Christopher Schultz wrote:

Robert,

On 3/16/21 14:33, Robert Turner wrote:

Chris,

I'm not sure if it will do what you want, but when sourcing Java-based SAML
libraries for our use as an SP, I too found that most of the libraries were
much larger and more complicated that I thought necessary. We went with the
(limited but simple to use) OneLogin libraries for our use case. It doesn't
do everything by any means, but was considerably smaller and simpler than
most packages out there.


I did see the OneLogin library. You mean this one, right?
https://github.com/onelogin/java-saml

Is there anything tied to any particular service for that? Or do they simply give-away 
their library for use anywhere?


Thanks,
-chris


On Tue, Mar 16, 2021 at 1:55 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

I've got a system which is accepting one-legged, signed SAML responses
from trusted third parties and going all the right things. It's working
great.

It's time to look at doing the opposite: assembling our own SAML
responses, signing them, and sending them to another party.

I'm sure I could manually create a DOM document with all the right
namespaces, add the various values that I need, and then use XML DSIG
using the bits and pieces that are provided by Java directly, but
there's got to be a nice compact library that doesn't require me to
download the entire internet in order to use in my product.

Any recommendations?

Thanks,
-chris

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






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




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



-
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: [OT] Working with SAML

2021-03-16 Thread tomcat/perl

Alternatively, see this : 
https://wiki.shibboleth.net/confluence/display/SP3/JavaHowTo

On 16.03.2021 21:18, Christopher Schultz wrote:

Robert,

On 3/16/21 14:33, Robert Turner wrote:

Chris,

I'm not sure if it will do what you want, but when sourcing Java-based SAML
libraries for our use as an SP, I too found that most of the libraries were
much larger and more complicated that I thought necessary. We went with the
(limited but simple to use) OneLogin libraries for our use case. It doesn't
do everything by any means, but was considerably smaller and simpler than
most packages out there.


I did see the OneLogin library. You mean this one, right?
https://github.com/onelogin/java-saml

Is there anything tied to any particular service for that? Or do they simply give-away 
their library for use anywhere?


Thanks,
-chris


On Tue, Mar 16, 2021 at 1:55 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


All,

I've got a system which is accepting one-legged, signed SAML responses
from trusted third parties and going all the right things. It's working
great.

It's time to look at doing the opposite: assembling our own SAML
responses, signing them, and sending them to another party.

I'm sure I could manually create a DOM document with all the right
namespaces, add the various values that I need, and then use XML DSIG
using the bits and pieces that are provided by Java directly, but
there's got to be a nice compact library that doesn't require me to
download the entire internet in order to use in my product.

Any recommendations?

Thanks,
-chris

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






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




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



Re: Run servlets on Nashorn written in server-side JavaScript

2021-02-17 Thread tomcat/perl

On 17.02.2021 14:59, Christopher Schultz wrote:

Rony and Leo,

On 2/17/21 02:58, Rony G. Flatscher (Apache) wrote:

Hi Leo,

why would you want to do that if you could do the same with Java? What is the 
motivation, the use

case for you?

How urgent is this (I may have something for both, Java EE and Jakarta EE, but need a 
little bit of

time)?

—-rony



On 15.02.2021 07:29, leo wrote:

Hi there

I am trying to find out how to process servlets written in server-side JavaScript 
through Tomcat.


I looked through the Tomcat FAQ and How-To but couldn't find anything. By googling I 
found a way

to hook up Python through Jython's PyServlet class. I tried this and it works 
great.

But I am looking for server-side JavaScript in Tomcat. I am aware of the 
JavaScript engine
Nashorn. Is there a way to hook up Nashorn with a servlet class, so that Tomcat serves 
JavaScript

servlets? Something like a "JavaScript Server Page" for Tomcat would be fine 
too.

Many thanks for any pointers,
Leo

ps: I use Tomcat 8.5, but I could move to another Tomcat version for this.


Weird; I never saw the OP on the list, only Rony's reply.

Usually if you want to use server-side JavaScript, you use something like Node.js instead 
of a servlet container. Why not use Node?


If you'd really like to use Tomcat, you will need to write a Servlet that establishes a 
JavaScript environment (e.g. Nashhorn), provides all the plumbing for the 
servlet-container provided resources (e.g. request, response, streams, session, etc.) as 
well as error-handling, etc.


It's a big job.

I'd be surprised is nobody had built something like this before. Or maybe everybody just 
uses Node.js.




+1.
On the face of it, it looks much simpler to set up a local Nodejs server, and proxy the 
corresponding requests from Tomcat to it.
Perhaps have a look at this ? 
https://stackoverflow.com/questions/42057314/how-to-implement-an-application-proxy-in-java-on-tomcat

Or use an Apache httpd front-end to filter requests and do the proxying to 
Nodejs and Tomcat.


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



Re: Tomcat server not considering Mime Type - Request urgent help!!

2021-01-15 Thread tomcat/perl

Hi again.
Sorry for the noise.
The page which you quoted 
(https://www.geeksforgeeks.org/http-headers-content-disposition/), itself contains a 
formal reference to
RFC 5987 (https://tools.ietf.org/html/rfc5987), which formally defines the extended 
"filename*" header parameter below.


On 15.01.2021 11:48, André Warnier (tomcat/perl) wrote:

On 14.01.2021 22:55, Christopher Schultz wrote:
Content-Disposition: attachment; filename="[filename]"; filename*=utf-8''[filename in 
UTF-8 encoding]


Hi Chris.
Do you have any reference for the above ?
(the "utf8''" part is new to me)


-
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 server not considering Mime Type - Request urgent help!!

2021-01-15 Thread tomcat/perl

On 14.01.2021 22:55, Christopher Schultz wrote:
Content-Disposition: attachment; filename="[filename]"; filename*=utf-8''[filename in 
UTF-8 encoding]


Hi Chris.
Do you have any reference for the above ?
(the "utf8''" part is new to me)


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



Re: Tomcat SSO valve implementation

2020-12-17 Thread tomcat/perl

On 16.12.2020 19:39, Kevin Oxley wrote:

We are trying to support SSO SAML 2.0 for user authentication in Tomcat
(9.0.22).   Can anybody provide a reference to a pre-integrated SAML SSO
valve implementation that you've had a good experience with?



searching Google for "SAML SP for servlet engine" gives a few links, among them 
this one :
https://dzone.com/articles/saml-single-sign-on-with-tomcat-and-picketlink

I haven't tried it myself. In my cases, I always use an Apache httpd front-end, which does 
the authentication prior to proxying to a back-end tomcat (with the Connector attribute ' 
tomcatAuthentication="false" '). In the front-end Apache2 httpd then, we use Shibboleth as 
the SAML SP side.

That works perfectly.

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



Re: Exit code 6 on shutting down Tomcat service

2020-09-30 Thread tomcat/perl

Hi.

On 30.09.2020 14:40, Jakub Moravec wrote:

Hello Tomcat team,

 we are having an issue that we were not able to resolve ourselves or
using the existing documentation, so I'd like to ask you for help.

 Description:

 During Tomcat service shutdown (using
command  /bin/tomcat9.exe //SS//), we sometimes
receive exit code 6. 


You may want to have a look at these :
- https://cwiki.apache.org/confluence/display/TOMCAT/Windows#Windows-Q11
- http://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html

These pages do not explain why you get an exit code 6 from tomcat9.exe.
But they explain what tomcat9.exe actually is, which may help for what follows 
(*)

The documentation page http://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html, 
 at the end, lists some additional tomcat9.exe command-line parameters (the ones starting 
with "--Log") which may enable you to find out more details about the internal error that 
triggers this exit code.

(e.g : --LogLevel "Debug")(and where to find that logfile)

The mailing list archives, at https://markmail.org/list/org.apache.commons.users/ may also 
help finding the reason (in the search box, enter "daemon", or "daemon exit")


(*) the tomcat9.exe program is actually a renamed copy of the Apache Commons Daemon 
"prunsrv" program, which the tomcat team adds to the tomcat-for-Windows package, to 
facilitate installing and running tomcat as a Windows service.



It happens underministically (or at least we don't

know the exact circumstances under which the error code is returned). We
were not able to find any information about this exit code or any
suggestions for fixes in the documentation.

  Environment:
  Tomcat: 9.0.33
  OS: Windows 2016, Version: 10.0, Flavor: Data Center

Thank you for your assistance!
Jakub Moravec
jakub.mora...@getmanta.com




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



Re: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)

2020-09-30 Thread tomcat/perl

On 30.09.2020 07:42, Arshiya Shariff wrote:

Hi Martin ,

Thank you for the response.

With a payload of 200 bytes we were able to send 20K requests/sec with 200 users from Jmeter without any memory issue . On increasing the payload to 5Kb and the number of users to 1000 in Jmeter and sending 1000 requests per second , the heap of 20GB got filled in 2 minutes . 


How long does it typically take (at the beginning of the test) for tomcat to *process* one 
of these requests ?


With 200 users the memory is cleared in the G1 mixed GC itself , but with 1000 users the 
memory is not cleared in the mixed GC , it takes full GCs of 7 to 10 seconds to clear the 
memory. These cases were executed with maxThreads 200 in tomcat , so we tried increasing 
the maxThreads from 200 to 1000, but still GC was struggling .


When we tried with 10 instances of JMeter , each with 100 users , where each 
instance was started with a delay of 1 minute we were able to see 1000 
connections created in tomcat without any memory issues. But when 1000 users 
are created using single instance of JMeter in 20 seconds , tomcat's memory is 
filling fast- 20GB in 2 minutes.
We suspect that the burst of connections being opened has a problem . Please 
help us with the same .

On analyzing the heap dump we see 
org.apache.tomcat.util.collections.SynchronizedStack occupying around 93% of 
3GB live data ,the remaining 17GB is Garbage collected in the heap dump.

Thanks and Regards
Arshiya Shariff

-Original Message-
From: Martin Grigorov 
Sent: Monday, September 28, 2020 11:44 PM
To: Tomcat Users List 
Subject: Re: HTTP2: memory filled up fast on increasing the connections to 
1000/2000 (Embedded tomcat 9.0.38)

Hi Arshiya,


On Mon, Sep 28, 2020 at 7:59 PM Arshiya Shariff 
 wrote:


Hi All,
With 200 threads(users) , ramp up duration of 2 seconds , loop count
80 and by sending 1000 http2 requests/sec from JMeter Client to an
embedded tomcat application we did not observe any memory issue , but
on sending
1000 http2 requests/sec with 2000 or 1000 users from JMeter , the
application's heap space of 20 GB is occupied in 2 minutes and after 2
full GCs the memory clears and comes down to 4GB (expected) .



I am not sure whether you follow the other discussions at users@.
In another email thread we discuss load testing Tomcat HTTP2 and we are able to make around 
12K reqs/s with another load testing tool - 
https://protect2.fireeye.com/v1/url?k=f8cfc13c-a66f0379-f8cf81a7-8692dc8284cb-2c0aae53194b790f=1=6a9c569d-7da1-4394-a9ac-bf72724992fa=https%3A%2F%2Fgithub.com%2Ftsenart%2Fvegeta
For me JMeter itself failed with OOM when increasing the number of the virtual 
users above 2K.
There are several improvements in Tomcat master and 9.0.x in the HTTP2 area. 
Some of the changes are not yet downported to 9.0.x. We still test them, trying 
to avoid introducing regressions in 9.0.x.




Embedded tomcat Version:9.0.38
Max Threads : 200



The number of threads should be less if you do only CPU calculations without 
IO/network. If your app blocks on IO/network calls then you need more spare 
threads.
With more threads there will be more context switches and less throughput.
That's why there is no one golden rule that applies to all applications.
200 is a good default that works for most of the applications. But you need to 
test with different values to see which one gives the best performance for your 
scenaria.



All other properties are the tomcat defaults.

Why is tomcat not able to process many connections ?



You can tell us by enabling -XX:+HeapDumpOnOutOfMemoryError and 
-XX:HeapDumpPath=. Once you have the .hprof file you can 
examine it with Eclipse Memory Analyzer tool and see what is leaking.
I will try to reproduce this issue tomorrow with Vegeta.



Why is the memory filled when the connections are increased, are there
any parameters to tune connections ?
Please let us know.

Thanks and Regards
Arshiya Shariff



-
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: WebSocket connection silently drops

2020-09-13 Thread Christopher Dodunski (Apache Tomcat)
It turns out that I was premature in concluding connections were 
silently getting dropped.


I left the client application running for another quarter hour after it 
stopped displaying message updates from the server.  On shutting it 
down, the server immediately recorded that the client had just 
disconnected.  This indicates that the WebSocket connection is not being 
silently dropped afterall, rather the client is becoming deaf to inbound 
messages after a few minutes.


Exactly why this is is a mystery.  But evidently it is a Tyrus rather 
than a Tomcat or network issue (they communicate across the internet, to 
answer your earlier question).


Regards,

Chris.

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



WebSocket connection silently drops

2020-09-13 Thread Christopher Dodunski (Apache Tomcat)

Hi,

I have a desktop application that, using the org.glassfish.tyrus 
WebSocket implementation, connects and talks with a parent web 
application running on Tomcat.  All runs well for a while but, after 
data transfer falls quiet for a few minutes, the connection gets 
silently dropped (nothing in the logs).


The ServerEndpoint onOpen() method sets the session to never timeout: 
session.setMaxIdleTimeout(0).  But this hasn't had the desired effect.


I've not (yet) implemented a game of ping pong to keep connections alive 
over long periods of time.  Still, I'd like to know why connections 
consistently get dropped after just a matter of minutes, and whether 
this can be resolved with a simple configuration change.


Web.xml is configured to keep sessions alive for 720 minutes, so the 
problem is not there.



720


WebSocket connections are handled by Tomcat port 8080, and as you can 
see this is set in server.xml to timeout after just 20 seconds.  I 
haven't tried extending this for fear it may have undesirable side 
effects.  Anyway, connections are dropping after several minutes, not 20 
seconds.


protocol="HTTP/1.1"

   connectionTimeout="2"
   redirectPort="8443" />

Any suggestions much appreciated.

Regards,

Chris.

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



Re: Tomcat Handling close_waits

2020-08-17 Thread tomcat/perl

Hi.

On 17.08.2020 02:51, Norbert Elbanbuena wrote:

Hi Paul,

Yes these are some samples, I have about 300 of them getting stuck hourly

tcp  761  0 192.168.1.50:58870  74.112.28.109:8011  CLOSE_WAIT
tcp0  0 192.168.1.50:56938  192.168.1.50:61616  CLOSE_WAIT
tcp0  0 192.168.1.50:56924  192.168.1.50:61616  CLOSE_WAIT
tcp0  0 192.168.1.50:56910  192.168.1.50:61616  CLOSE_WAIT
tcp0  0 192.168.1.50:56912  192.168.1.50:61616  CLOSE_WAIT
tcp6   0   6240 192.168.1.50:44352.11.72.45:47123   CLOSE_WAIT
tcp6  32  0 192.168.1.50:44334.209.104.242:13402CLOSE_WAIT
tcp6 268  0 192.168.1.50:443108.162.244.28:40864CLOSE_WAIT
tcp6  32  0 192.168.1.50:44335.167.185.49:10019 CLOSE_WAIT
tcp6  32  0 192.168.1.50:44352.24.48.141:60660  CLOSE_WAIT
tcp6 202  0 192.168.1.50:443199.189.191.86:51716CLOSE_WAIT
tcp6 202  0 192.168.1.50:443199.189.191.86:1386 CLOSE_WAIT




Try forcing a Java Garbage Collection in Tomcat, and check if these CLOSE_WAIT sockets are 
still there after that. If they are gone, you probably have a server application which 
leaves these sockets "dangling" and does not properly close them.


Other people on this list may be able to provide a simpler way to trigger a GC, but I used 
a script with "jmxsh", like this :


# gc_tomcat.jmxsh
# force the target JVM to do a GC, from the jmxsh shell
# invoke as :
# java -jar jmxsh.jar gc_tomcat.jmxsh
#
# In the following command, replace the port number (-p)
#   by the port which has been specified in the parameter :
#   -Dcom.sun.management.jmxremote.port=x
#   of the target Java JVM startup line
jmx_connect -h 127.0.0.1 -p (port) -U (userid) -P (password)
jmx_invoke -m java.lang:type=Memory gc
jmx_close

for jmxsh, see :
- https://github.com/davr/jmxsh
- http://isbyr.com/use-jmxsh-jmx-cli-tool-to-troubleshoot-remote-jmx-connection/





Warm regards,

Norbert

-Original Message-
From: Paul Carter-Brown 
Sent: Sunday, August 16, 2020 2:43 PM
To: Tomcat Users List 
Subject: Re: Tomcat Handling close_waits

Hi Norbert,

The TCP socket states and timers are managed by the underlying OS and not by 
Tomcat. Can you paste a netstat -an result so I can see what you mean.
Also, is the client using HTTP 1.1 with keep-alive or not? What kind of traffic 
is this?

Paul


On Sun, Aug 16, 2020 at 7:16 PM Norbert Elbanbuena 
wrote:


I also noticed that while server receives the connection requests, we
are seeing multiple requests from the same sources. Some same source
requests
(FIN-WAIT) are all in state while other same sources requests are in
other state (some in FIN-WAIT or close_wait and some Established).

Why are we seeing multiple requests from the same source at the same time?
Doesn't each socket request exhaust a thread on the application?


Warm regards,

Norbert Elbanbuena

-Original Message-
From: Norbert Elbanbuena 
Sent: Sunday, August 16, 2020 11:35 AM
To: Tomcat Users List 
Subject: Tomcat Handling close_waits

Hi,

We are experiencing a flood of close_waits in our server.
Interestingly, all of the sessions stuck in close_waits are sourced
from Amazon IP addresses. Our second server running the same setup
(hardware spec, OS version, Tomcat version, etc.) and had almost the
same session count and our application and Tomcat didn't go unresponsive.

Is there any tuneable parameter for the APR connector for Tomcat to
close the stuck sessions, rather than waiting for the application?

Warm regards,

Norbert Elbanbuena


-
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 9.0.36 - JDK 13/14

2020-07-02 Thread tomcat/perl



On 02.07.2020 10:23, Utkarsh Bhargav wrote:

Please i have resolved my issue Kindly stop sending mails



Hi. You receive these emails because you subscribed to the email list 
"users@tomcat.apache.org".
To not receive these emails anymore, you should unsubscribe from the list, be sending an 
email (from the same email address which you used to subscribe), *as indicated at the end 
of every email that you receive from the list*.

(including this one)

[...]


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



Re: NullPointerException on statrup - possible bug in Tomcat

2020-06-24 Thread tomcat-subs
Problem resolved. Thank you.

On Wed, Jun 24, 2020, at 12:46 PM, Konstantin Kolinko wrote:
> ср, 24 июн. 2020 г. в 19:25, :
> >
> > I have a web application which is failing in RestEasy initialization with 
> > an NPE. It worked for many years until I added a large number of jar 
> > dependencies because of a new development effort. I've debugged the code by 
> > stepping through the Tomcat source to the point I've found where it is 
> > failing. It seems to be a Tomcat bug but of course I'm not convinced since 
> > it is highly more likely it is my problem.
> >
> > Tomcat version is 9.0.36, though the failure happens in the Tomcat 8 
> > versions I've tried as well.
> >
> > The NPE is triggered by a single "return null" statement in 
> > org.apache.catalina.core.ApplicationContext line 933. Below is a code 
> > snippet of where the return statement is. In my failing scenario the 
> > wrapper is NOT null and isOverridable is already returning false. So it 
> > falls through to return null.
> >
> > So here is my question: Why in the world in the code below does the return 
> > null statement even exist? It seems like the return null at line 933 is the 
> > precondition the code is trying to establish.
> 
> This method is documented in the specification of Servlet API (in
> their javadoc) to return null if such servlet has already been
> registered.
> See Java EE 8 javadoc
> https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#addServlet-java.lang.String-java.lang.Class-
> 
> (Following the links from Specifications page
> https://cwiki.apache.org/confluence/display/TOMCAT/Specifications
> 
> K.Kolinko
> 
> -
> 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



NullPointerException on statrup - possible bug in Tomcat

2020-06-24 Thread tomcat-subs
I have a web application which is failing in RestEasy initialization with an 
NPE. It worked for many years until I added a large number of jar dependencies 
because of a new development effort. I've debugged the code by stepping through 
the Tomcat source to the point I've found where it is failing. It seems to be a 
Tomcat bug but of course I'm not convinced since it is highly more likely it is 
my problem.

Tomcat version is 9.0.36, though the failure happens in the Tomcat 8 versions 
I've tried as well.

The NPE is triggered by a single "return null" statement in 
org.apache.catalina.core.ApplicationContext line 933. Below is a code snippet 
of where the return statement is. In my failing scenario the wrapper is NOT 
null and isOverridable is already returning false. So it falls through to 
return null.

So here is my question: Why in the world in the code below does the return null 
statement even exist? It seems like the return null at line 933 is the 
precondition the code is trying to establish.

//code from 'org.apache.catalina.core.ApplicationContext'
Wrapper wrapper = (Wrapper) context.findChild(servletName);

// Assume a 'complete' ServletRegistration is one that has a class and
// a name
if (wrapper == null) {
wrapper = context.createWrapper();
wrapper.setName(servletName);
context.addChild(wrapper);
} else {
if (wrapper.getName() != null &&
wrapper.getServletClass() != null) {
if (wrapper.isOverridable()) {
wrapper.setOverridable(false);
} else {
return null; // Line 933
}
}
}

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



Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?

2020-05-16 Thread tomcat/perl

In summary, yes, I think you're right in your final conclusion below.

If the tomcat access log shows the authenticated user, it means that tomcat got it, and I 
see no other way than from Apache and through that "tomcatAuthentication=false" option of 
the tomcat AJP connector.


And that in turn means that, for Apache, this request was authenticated, which in turn 
means that OAM /did/ also set the Apache-internal R->user variable.


The values printed by your Apache cgi-bin script are maybe a bit confusing regarding what 
is going on, because they are the result of a different (and parallel) process : when 
Apache runs a cgi-bin script, it does this in a separate child process, and when it 
creates this process, it provides it with an environment. And that is what your cgi-bin 
script is showing (it's own environment values).
That in this environment, Apache creates a "remote-user" variable and populates it with 
the Apache authenticated user-id, is fortuitous but unrelated to the fact that 
Apache+mod_proxy_ajp *also* passes this authenticated user-id via AJP to tomcat.


So now indeed, you have to figure out why this tomcat webapp wants the browser to retrieve 
a login page, despite the fact that this access is already authenticated.
But indeed this is no longer an Apache or a tomcat or tomcat Connector issue, it is a 
webapp logic or configuration issue.



On 16.05.2020 08:40, ohaya wrote:

  Hi,

When I configure the OAM protection, they have the ability to configure values 
that go into HTTP headers (among other things) upon successful authentication 
(to OAM).

I usually test this by protecting /cgi-bin/printenv on the Apache. printenv has 
this :

##
## printenv -- demo CGI program which just prints its environment
##
use strict;
use warnings;

print "Content-type: text/plain; charset=iso-8859-1\n\n";
foreach my $var (sort(keys(%ENV))) {
  my $val = $ENV{$var};
  $val =~ s|\n|\\n|g;
  $val =~ s|"|\\"|g;
  print "${var}=\"${val}\"\n";

and when do that test, it does dump out remote_user (among others).

Also FYI, I was just looking at the Tomcat localhost_access_log..txt 
file, and I am seeing lines like:

xx.0.xx.xx -  [16/May/2020:06:18:41 +] "GET /xxx/login 
HTTP/1.1" 302 -

where  is the username of the user that authenticated to OAM.

I am not 100% about the format of that log, but does that line say that Tomcat thinks 
that the user that is logged INTO TOMCAT is that ?

If so, then does that mean that I am already passing that user from Apache into 
Tomcat successfully?

If so, I have thinking that maybe the webapp that I am trying to get logged 
into (it is Apache Syncope) is not leveraging the authentication mechanisms 
that are inbuilt in Tomcat?

That kind of makes sense, because I know that I didn't have to add that user to 
the tomcat-users.xml.

Finally if that is the case, this is no longer just a Tomcat-related issue.

Jim


  On Friday, May 15, 2020, 09:38:19 AM EDT, Christopher Schultz 
 wrote:
  
  -BEGIN PGP SIGNED MESSAGE-

Hash: SHA256

Jim,

On 5/15/20 08:42, ohaya wrote:

Yes, I am using Oracle Access Manager (OAM) so we have what they
call an "OAM webgate" that is integrated with the Apache. That
webgate automatically populates an HTTP header named "remote_user"
with the user that OAM authenticated.

So the problem I having is trying to figure out how to "integrate"
that with Tomcat.


Okay.


So we have:

Browser <==> Apache+webgate <==> Tomcat (webapp)


Good.

First thing's first: Do you get your pages from Tomcat, but you aren't
authenticated, or do you get some other kind of error? Sounds like you
see your application, just no authentication.

If this is your first time doing this, I assume you mean you're trying
to figure out how to get it done, not trying to move a working
configuration from another environment./version to Tomcat 9, right?

There is nothing in the configuration you have posted so far that
leads me to believe you'll be sending any REMOTE_USER HTTP header to
Tomcat. Apache httpd doesn't (usually) auto-forward anything to
Tomcat. Your OAS module is more likely setting an environment variable
(remote_user) than an HTTP header. But it might be setting a header.
That would be good information to know.

To send arbitrary headers (etc.) to Tomcat via mod_proxy_ajp, you need
to configuration to do that. Let's take a look at the Tomcat
documentation to see how tomcatAuthentication="false" works.

Awesome, the documentation says nothing about how to tie-into it.
Well, the code says that tomcatAuthentication="false" means that AJP
can accept the REMOTE_USER /request attribute/ which is a special
servlet-thing which isn't the same as a header. So you have to arrange
for mod_proxy_ajp to send your "remote_user" (header or environment
variable) to Tomcat as a request attribute.

Here's how to do that. 

Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?

2020-05-15 Thread tomcat/perl

On 15.05.2020 14:42, ohaya wrote:

  Hi,

Yes, I am using Oracle Access Manager (OAM) so we have what they call an "OAM webgate" 
that is integrated with the Apache. That webgate automatically populates an HTTP header named 
"remote_user" with the user that OAM authenticated.

So the problem I having is trying to figure out how to "integrate" that with 
Tomcat.


Then you would need an Apache add-on module which grabs the content of this header, and 
sets the Apache R->user variable (where R is the Apache request object).
And in Tomcat, your Connector, as it is shown below, will automatically pick up this 
user-id and use it within tomcat.


There is probably already an option in OAM which does this (set the Apache user at the 
same time as adding that HTTP header REMOTE_USER). That is what it should do anyway, if 
OAM can also authenticate the user for an application running within Apache.




So we have:

Browser <==> Apache+webgate <==> Tomcat (webapp)

Jim


  On Friday, May 15, 2020, 08:36:18 AM EDT, André Warnier (tomcat/perl) 
 wrote:
  
  Let me give my 5 cent.


In the tomcat AJP Connector Tomcat, you use the tomcatAuthentication attribute :



This setting has the effect that tomcat will "believe" the authenticated 
user-id that
Apache is passing to it in the AJP protocol messages that Apache sends to 
tomcat, and not
try to re-authenticate again at the tomcat level.
(Note : this is not done by a "REMOTE_USER" HTTP header added by Apache; it 
happens via
some internal variable specific to the AJP protocol).

Of course, for this, the request needs to be first authenticated in Apache (so 
that it has
a user-id to pass to tomcat).

So do you have anything at the Apache httpd side, which authenticates the user 
before the
request gets passed to tomcat (via AJP) ?




On 15.05.2020 14:08, ohaya wrote:

   Hi Olaf,

Thanks. I do appreciate that! I will do more digging.

Jim


       On Friday, May 15, 2020, 07:41:50 AM EDT, Olaf Kock  
wrote:
   
   
On 15.05.20 13:23, ohaya wrote:

     Hi,

I just tried adding the secret to the Apache side:

ProxyPass ajp://192.168.218.XXX:8009 secret="123"
ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123"

and I get an error when I try to start Apache:

AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf:
ProxyPass unknown Worker parameter

I am currently using Apache 2.4.39. Is there another way to specify the 
"secret"?


With 9.0.20 you do not yet need to pass a secret - that came along later
(somewhere around 30-33 AFAIR). However, you'll need to make sure that
your AJP port is only available for the reverse proxy and nobody else -
there was a recent security disclosure, which led to the change of many
default settings for the AJP connector in the current releases.

It boils down to the last sentence of my previous answer: I've never
used REMOTE_USER headers for authentication, and there's no indicator in
your setup that you're allowing Tomcat to trust such a header. I might
be completely off here, but as nobody else answered yet, I thought I'd
give it a try.

Olaf


Thanks,
Jim


         On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya 
 wrote:
 
     Hi,


The Tomcat version I am using is 9.0.20. I will take a look at the changelog.

This is the first time I have tried this, and I couldn't find much info, so I appreciate 
the feedback. I will look for info about "secret".

I wasn't sure about the format on the Apache side for the 
ProxyPass/ProxyPassReverse - does what I posted look all right?

Also, when I was searching around for info, I saw some comments that seem to be saying 
that the "tomcatAuthentication" parameter on the Tomcat connection was no 
longer supported or something like that?

Also re. "secret" on the Tomcat side: If that is set to, for example, 
"mysecret", how do I pass that on the Apache side?

Thanks again,
Jim


       On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock  
wrote:
 
 
On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote:

Hi,

I am using an Apache proxy in front of Tomcat 9, and I am using AJP connection 
to connect from the Apache to Tomcat, and I have the Apache sending a username 
to the Tomcat in a REMOTE_USER header.

In the Tomcat server.xml I have:

     

In the Apache httpd.conf, to test, this I have:


ProxyPass ajp://192.168.218.XX:8009
ProxyPassReverse ajp://192.168.XX.224:8009


But when I access the app via the Apache, it is not automatically logging me 
into the app.

Is there anything else that I have to do to get this to work besides what I did 
above?  Is there something that I have to modify in the app itself to get this 
to work?

Hi Jim,

which exact version of Tomcat 9 are you using? Note that there were
significant changes for the default and required configuration for the
AJP connector, in order to use it. Best to f

Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?

2020-05-15 Thread tomcat/perl

Let me give my 5 cent.

In the tomcat AJP Connector Tomcat, you use the tomcatAuthentication attribute :



This setting has the effect that tomcat will "believe" the authenticated user-id that 
Apache is passing to it in the AJP protocol messages that Apache sends to tomcat, and not 
try to re-authenticate again at the tomcat level.
(Note : this is not done by a "REMOTE_USER" HTTP header added by Apache; it happens via 
some internal variable specific to the AJP protocol).


Of course, for this, the request needs to be first authenticated in Apache (so that it has 
a user-id to pass to tomcat).


So do you have anything at the Apache httpd side, which authenticates the user before the 
request gets passed to tomcat (via AJP) ?





On 15.05.2020 14:08, ohaya wrote:

  Hi Olaf,

Thanks. I do appreciate that! I will do more digging.

Jim


  On Friday, May 15, 2020, 07:41:50 AM EDT, Olaf Kock  
wrote:
  
  
On 15.05.20 13:23, ohaya wrote:

   Hi,

I just tried adding the secret to the Apache side:

ProxyPass ajp://192.168.218.XXX:8009 secret="123"
ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123"

and I get an error when I try to start Apache:

AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf:
ProxyPass unknown Worker parameter

I am currently using Apache 2.4.39. Is there another way to specify the 
"secret"?


With 9.0.20 you do not yet need to pass a secret - that came along later
(somewhere around 30-33 AFAIR). However, you'll need to make sure that
your AJP port is only available for the reverse proxy and nobody else -
there was a recent security disclosure, which led to the change of many
default settings for the AJP connector in the current releases.

It boils down to the last sentence of my previous answer: I've never
used REMOTE_USER headers for authentication, and there's no indicator in
your setup that you're allowing Tomcat to trust such a header. I might
be completely off here, but as nobody else answered yet, I thought I'd
give it a try.

Olaf


Thanks,
Jim


       On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya 
 wrote:
   
   Hi,


The Tomcat version I am using is 9.0.20. I will take a look at the changelog.

This is the first time I have tried this, and I couldn't find much info, so I appreciate 
the feedback. I will look for info about "secret".

I wasn't sure about the format on the Apache side for the 
ProxyPass/ProxyPassReverse - does what I posted look all right?

Also, when I was searching around for info, I saw some comments that seem to be saying 
that the "tomcatAuthentication" parameter on the Tomcat connection was no 
longer supported or something like that?

Also re. "secret" on the Tomcat side: If that is set to, for example, 
"mysecret", how do I pass that on the Apache side?

Thanks again,
Jim


     On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock  
wrote:
   
   
On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote:

Hi,

I am using an Apache proxy in front of Tomcat 9, and I am using AJP connection 
to connect from the Apache to Tomcat, and I have the Apache sending a username 
to the Tomcat in a REMOTE_USER header.

In the Tomcat server.xml I have:

   

In the Apache httpd.conf, to test, this I have:


ProxyPass ajp://192.168.218.XX:8009
ProxyPassReverse ajp://192.168.XX.224:8009


But when I access the app via the Apache, it is not automatically logging me 
into the app.

Is there anything else that I have to do to get this to work besides what I did 
above?  Is there something that I have to modify in the app itself to get this 
to work?

Hi Jim,

which exact version of Tomcat 9 are you using? Note that there were
significant changes for the default and required configuration for the
AJP connector, in order to use it. Best to find all of them: Search for
AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html

Notable among them: Everything to do with "secret", and the default bind
address, "localhost", for the AJP connector. i.e. I'd expect this
configuration to be insufficient for any of the latest releases.

I haven't ever used this REMOTE_USER authentication, but nothing in the
configuration that you've posted gives any clue about what you do and
what you send. I would expect Tomcat to *not* blindly accept any
REMOTE_USER header by default, unless it's whitelisted and explicitly
asked for - it otherwise would be a great way to exploit servers that
don't have a remote proxy (or one where the remote proxy is configured
to remove this header). Nothing in the configuration you post gives me a
hint about what you do to make tomcat accept and trust this header.

Olaf



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




--

Re: Changing the Java using by Tomcat

2020-05-06 Thread tomcat/perl

On 06.05.2020 10:55, Reddy, Tippana Krishnanandan wrote:

Hi All,

We are using tomcat 9.0.6 and we want to change existing JAVA used by tomcat 
and replace it Adopt openJDK without uninstalling the tomcat.

Is this possible? if so can anyone please send us details how to approach this.



I don't think that there is anything in the tomcat configuration itself that 
must be changed.
It will consists mostly of changes to the tomcat startup scripts.
Under what OS are you running tomcat ? and how was it installed ?


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



Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-05-01 Thread tomcat/perl

On 01.05.2020 20:32, Darryl Philip Baker wrote:

Continuing the investigation:

I have the two tomcat installation in /opt/tomcat. Apache HTTPD references the worker file using a 
path that has a symbolic link that "latest" I can switch to point to either installation 
of tomcat. The workers file is defined in httpd.conf as "JkWorkersFile 
/opt/tomcat/latest/conf/jk/workers.properties"

Tomcat 9.0.20 works as expected. Tomcat 9.0.34 fails with just having the 
browser clocking and not returning.


I think you may have gotten everyone confused now because

1) you cannot have 2 different tomcat installations under the same directory (/opt/tomcat 
in your above explanation)

2) previously, you wrote that the error in one case was that you got back a 404 
error.
Now you are saying that the browser is just waiting and "not returning".
3) in the diff output below, it seems that you have a line like

>>   worker.worker1.secret="false"

in one of the "server.xml" files (although it appears to be part of a comment).
That is not where such a line belongs.

Can you be more precise in exactly describing your installation, how you are starting one 
tomcat or the other, how you switch between them, and what happens ?


P.S. I would recommend moving yourt workers.properties file away from the tomcat 
directories, and into some httpd configuration directory, because that file has in fact 
nothing to do with tomcat. It is read by the mod_jk module, which is a module running in 
httpd, not tomcat.





Just to give you an idea of the differences in the control files:

[[root@lmsdevsyncapp7 tomcat]# diff apache-tomcat-9.0.20/conf/server.xml 
apache-tomcat-9.0.34/conf/server.xml
79c79
< 

119d121
< address="127.0.0.1"
[root@lmsdevsyncapp7 tomcat]# diff 
apache-tomcat-9.0.20/conf/jk/workers.properties 
apache-tomcat-9.0.34/conf/jk/workers.properties
[root@lmsdevsyncapp7 tomcat]# ls -l
total 8
drwxrwxr-x 9 tomcat tomcat 4096 May 16  2019 apache-tomcat-9.0.20
drwxr-xr-x 9 tomcat tomcat 4096 Apr 28 11:59 apache-tomcat-9.0.34
lrwxrwxrwx 1 root   root 20 Apr 28 15:00 latest -> apache-tomcat-9.0.34
[root@lmsdevsyncapp7 tomcat]#


Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL  60201-3715
darryl.ba...@northwestern.edu
(847) 467-6674
  


On 4/30/20, 5:09 PM, "Darryl Philip Baker"  
wrote:

 I am trying to browse to one of the JKmount URLs in this case 
https://myserver.northwestern.edu/LmsSync/. When I point the symbolic link to 
the 9.0.20 installation, it works fine. When I point the symbolic link to the 
9.0.34 installation, it I get a 404 error.

 Darryl Baker, GSEC  (he/him/his)
 Sr. System Administrator
 Distributed Application Platform Services
 Northwestern University
 1800 Sherman Ave.
 Suite 6-600 – Box #39
 Evanston, IL  60201-3715
 darryl.ba...@northwestern.edu
 (847) 467-6674


 On 4/30/20, 3:35 PM, "Christopher Schultz"  
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Darryl,

 On 4/30/20 07:59, Darryl Philip Baker wrote:
 > I am trying to upgrade a development environment from 9.0.20 to
 > 9.0.34 and I am having issues getting the tomcat-connectors-1.2.46
 > (mod_jk) to work in with the new version.

 Can you be more specific? What are you trying, and how is it (not)
 working, specifically?

 > The Apache HTTPD configuration remains unchanged the paths pass
 > through a symbolic link I change to switch versions. The
 > workers.properties file was copied over and is identical. I added
 > the same definition for the AJP connector into server.xml. I will
 > place the pieces I modified below.> Server.xml:   protocol="AJP/1.3" redirectPort="443" address="127.0.0.1"
 > enableLookups="false" tomcatAuthentication="false"
 > secretRequired="false" maxPostSize="10" />
 >
 > Workers.properties: #define 1st worker using worker1
 > worker.list=worker1
 >
 > #set properties for the worker1 worker worker.worker1.type=ajp13
 > worker.worker1.host=127.0.0.1 worker.worker1.port=8009
 > worker.worker1.lbfactor=50 worker.worker1.cachesize=10
 > worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1
 > worker.worker1.recycle_timeout=300

 At first glance, this configuration looks fine to me.

 - -chris
 -BEGIN PGP SIGNATURE-
 Comment: Using GnuPG with Thunderbird - 
https://urldefense.com/v3/__https://www.enigmail.net/__;!!Dq0X2DkFhyF93HkjWTBQ

Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-04-30 Thread tomcat/perl

On 01.05.2020 00:09, Darryl Philip Baker wrote:

I am trying to browse to one of the JKmount URLs in this case 
https://myserver.northwestern.edu/LmsSync/. When I point the symbolic link to 
the 9.0.20 installation, it works fine. When I point the symbolic link to the 
9.0.34 installation, it I get a 404 error.


Ah, here may be a clue : the 404 error page returned by Apache httpd looks significantly 
different from the 404 error page returned by Tomcat (in look). Which one are you getting ?
If you get the Apache httpd version, then the problem is that Apache httpd/mod_jk is not 
even trying to forward the call to Tomcat, and tries to map it locally to the Apache 
document space.
Conversely, if you get the Tomcat version, then it means that the call /is/ forwarded by 
httpd/mod_jk to Tomcat, but that it is tomcat somehow which does not find anything in its 
URL space that matches the forwarded link URL.




Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL  60201-3715
darryl.ba...@northwestern.edu
(847) 467-6674
  


On 4/30/20, 3:35 PM, "Christopher Schultz"  
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Darryl,

 On 4/30/20 07:59, Darryl Philip Baker wrote:
 > I am trying to upgrade a development environment from 9.0.20 to
 > 9.0.34 and I am having issues getting the tomcat-connectors-1.2.46
 > (mod_jk) to work in with the new version.

 Can you be more specific? What are you trying, and how is it (not)
 working, specifically?

 > The Apache HTTPD configuration remains unchanged the paths pass
 > through a symbolic link I change to switch versions. The
 > workers.properties file was copied over and is identical. I added
 > the same definition for the AJP connector into server.xml. I will
 > place the pieces I modified below.> Server.xml:   protocol="AJP/1.3" redirectPort="443" address="127.0.0.1"
 > enableLookups="false" tomcatAuthentication="false"
 > secretRequired="false" maxPostSize="10" />
 >
 > Workers.properties: #define 1st worker using worker1
 > worker.list=worker1
 >
 > #set properties for the worker1 worker worker.worker1.type=ajp13
 > worker.worker1.host=127.0.0.1 worker.worker1.port=8009
 > worker.worker1.lbfactor=50 worker.worker1.cachesize=10
 > worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1
 > worker.worker1.recycle_timeout=300

 At first glance, this configuration looks fine to me.

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

 iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6rNncACgkQHPApP6U8
 pFh5nA//RMgbj+pgTSUqUq7zUaFvzEudyp3kfGDI7As7uvmE2BOwYABPtXjKniRF
 2r/whNKQDu8VGOAp1JwTamPGpuNSh9pHW8KVqoTkr3Hg47E9fl86zE3a33/Gzq4G
 Q72SZNmIyZtDvkf7autdSUXUeb1DX4KJcX7O42c7TzYp6APb82u/NUwDLRBD24FK
 dVkMtkdoUgG19tsjLVNalGRkTgBNHC1ySIFikn0Tsd/28ApxCOtApn5Y85JxkjNh
 GwoxbFXjTtGDVVq3Yo039xelALdquk9mm5BdA1UyANTcOx1s2VZozlVy1ayPMHNm
 zPgqWLdhgRipAiLqDrPiE4u1R1PQ9wr/klQragHwY5LTzby8x1V7PAn4RZw0BRrt
 yPCIAoI+dEnsiMRxfnVuNYHYbqMjTKlEF4M2zBKYuq6bpGKZEw8/IoK86kEAFYR5
 trVt3o2uJ/qhn/34m4F30ilTXm7DR389ZaZ83nF4dihsst9aNmZuSUCZ6qEHTbNC
 Tk1v7p+GxMJQwLglr63hfhNTij3zJPbZjQ9NXza7UiLYqqkzStXJX9JeUCjHmKsq
 V6Ageh0STQm7zjRSsFse0QGP21anIxqmzkD6MmZE85v0Wsbe5gEzHXvGVpb5NdHe
 ClWrI8H94YGG9XeZePvD2hlMNwCwATqJlev+IKk5WyPE+zI8BkM=
 =NL+W
 -END PGP SIGNATURE-


-
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: Losing session between calls from mobile phone

2020-04-28 Thread tomcat/perl

On 28.04.2020 18:28, AJ Chen wrote:

Thanks. Martin and Mark.

I can recreate the problem: I compare two different mobile phones. One
phone can log in and proceed. Server log shows the same session persists
(same sessionID upon different requests). The other phone can log in, but
upon next request, server log show a new session is always created (new
sessionId).

Since session tracking works on PC browser and some mobile phone, the proxy
(if any) in front of aws EC2 server should not be the problem.Anything
else may be missing?



Asking just in case :
- are the 2 phones on the same network carrier ?
- are they the same brand, or at least OS ?
- if you connect them both to the same local WiFi, do they still act 
differently ?

Note : no idea if this makes any difference, but we're trying to find a reason why they 
act differently when using the same Internet application server, right ?



-aj


On Tue, Apr 28, 2020 at 12:30 AM Mark Thomas  wrote:


On 28/04/2020 07:47, Martin Grigorov wrote:

On Tue, Apr 28, 2020 at 9:11 AM AJ Chen  wrote:


Anyway to fix it? thanks. -aj



First you need to investigate whether there is a proxy.
Then what kind of proxy.
Then where is its configuration.
Then consult with its manual and see whether there is something
wrong/missng.


I'd recommend taking a step back.

Guessing at what might be wrong and then trying to fix the problem you
have only guessed at is unlikely to work.

Can you recreate the problem? You can't tell if something is fixed if
you can't recreate it.

Once you recreate the problem then you can start to narrow it down. You
need to track what is happening to the session ID. You'll probably need
to add some information to the access log, possibly look at some raw
network logs and/or look at HTTP headers on the client..

Somewhere in all of the above you should find out where the session ID
is getting dropped. Then you need to figure out why. Only then you know
why this is happening can you start to think about a solution.

Mark








On Mon, Apr 27, 2020 at 10:54 PM Martin Grigorov 
wrote:


Hi,

On Tue, Apr 28, 2020 at 2:23 AM AJ Chen 

wrote:



My web application using tomcat 6 can track user session (cookie by
default) for mobile and PC users in dev environment. But when deployed

on

cloud server, it fails to track session for some mobile users.

meaning,

servlet always creates a new session upon user request.

Any idea why this happens?



Most probably there is a proxy in front of Tomcat in the cloud

environment

which does not properly forward the JSESSIONID cookie.

Martin




aj










-
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: Why does Tomcat open connections on localhost?

2020-03-31 Thread tomcat/perl

On 31.03.2020 15:30, Mark Thomas wrote:

On 31/03/2020 13:29, André Warnier (tomcat/perl) wrote:

On 31.03.2020 14:20, Mark Thomas wrote:

On 31/03/2020 11:20, Aditya Kumar wrote:

Tomcat 9.0.30 on Windows Server 2012 / Java 1.8

I've noticed on a freshly installed version of tomcat 9, upon startup
there
are several connections to and from localhost on different ports

For example on my tomcat server there are 4 connections to and from
localhost (output from netstat)

   TCP    0.0.0.0:8080   0.0.0.0:0
LISTENING   3972
   TCP    127.0.0.1:55618    127.0.0.1:55619
ESTABLISHED 3972
   TCP    127.0.0.1:55619    127.0.0.1:55618
ESTABLISHED 3972
   TCP    127.0.0.1:55620    127.0.0.1:55621
ESTABLISHED 3972
   TCP    127.0.0.1:55621    127.0.0.1:55620
ESTABLISHED 3972
   TCP    [::]:8080  [::]:0
LISTENING   3972

These can grow to a large number (several thousand) on a busy system.
What
are these connections used for? What caused them? What thread are they
attributed to?


The Java NIO implementation on Windows uses TCP for intra-process
signalling. It opens a pair of self-connected sockets for every Selector.

Mark



While we're at it, under Linux, are the following for a similar reason ?

output of :  netstat -pan | grep 27514   (tomcat's JVM PID = 27514)
[...]
unix  2  [ ] STREAM CONNECTED 167427210 27514/java
unix  2  [ ] STREAM CONNECTED 167423436 27514/java


Don't know. One possible way to check would be to add an additional NIO
connector and see if you get more of them.



Note : this is not very important, was just curiosity

But Nope.

I added a second HTTP Connector (port 8180), which by default should be NIO :





and restarted tomcat, but the number of listed unix sockets remains the same :

root@xxx:~# netstat -pan | grep 32647  (tomcat 8.5 has a new PID)
tcp6   0  0 127.0.0.1:8005  :::*LISTEN  
32647/java
tcp6   0  0 127.0.0.1:8009  :::*LISTEN  
32647/java
tcp6   0  0 :::8080 :::*LISTEN  
32647/java
tcp6   0  0 127.0.0.1:8180  :::*LISTEN  
32647/java
tcp6   0  0 127.0.0.1:8009  127.0.0.1:45190 ESTABLISHED 
32647/java
unix  2  [ ] STREAM CONNECTED 190838270 32647/java
unix  2  [ ] STREAM CONNECTED 190846897 32647/java
root@darwin:~#


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



Re: Why does Tomcat open connections on localhost?

2020-03-31 Thread tomcat/perl

On 31.03.2020 14:20, Mark Thomas wrote:

On 31/03/2020 11:20, Aditya Kumar wrote:

Tomcat 9.0.30 on Windows Server 2012 / Java 1.8

I've noticed on a freshly installed version of tomcat 9, upon startup there
are several connections to and from localhost on different ports

For example on my tomcat server there are 4 connections to and from
localhost (output from netstat)

  TCP0.0.0.0:8080   0.0.0.0:0  LISTENING   3972
  TCP127.0.0.1:55618127.0.0.1:55619ESTABLISHED 3972
  TCP127.0.0.1:55619127.0.0.1:55618ESTABLISHED 3972
  TCP127.0.0.1:55620127.0.0.1:55621ESTABLISHED 3972
  TCP127.0.0.1:55621127.0.0.1:55620ESTABLISHED 3972
  TCP[::]:8080  [::]:0 LISTENING   3972

These can grow to a large number (several thousand) on a busy system. What
are these connections used for? What caused them? What thread are they
attributed to?


The Java NIO implementation on Windows uses TCP for intra-process
signalling. It opens a pair of self-connected sockets for every Selector.

Mark



While we're at it, under Linux, are the following for a similar reason ?

output of :  netstat -pan | grep 27514   (tomcat's JVM PID = 27514)
[...]
unix  2  [ ] STREAM CONNECTED 167427210 27514/java
unix  2  [ ] STREAM CONNECTED 167423436 27514/java



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



Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?

2020-03-28 Thread tomcat/perl

On 27.03.2020 21:39, Eric Robinson wrote:

FYI, I don't have 1800 tomcat instances on one server. I have about 100 
instances on each of 18 servers.


When one of these (attempted) connections fails, do you not get some error message which 
gives a clue as to what the failure is due to ?

(should be a log somewhere, no ?)

Also, just for info :
in the past, I have run into problems under Linux (no more connections accepted, neither 
incoming nor outgoing) whenever the actual number of TCP connections went above a certain 
number (maybe it was 64K).
A TCP connection goes through a number of states (which you see with a netstat display), 
such as "ESTABLISHED" but also "TIME_WAIT", "CLOSE_WAIT" etc.. In some of these states, 
the connection no longer has any link to any process, but the connection still counts 
against the limit (of the OS/TCP stack).


The case I'm talking about was a bit like yours : a webapp running under tomcat was making 
a connection to a remote host, but this connection was wrapped inside an object of some 
kind. When the webapp no longer needed the connection, it just discarded the wrapping 
object, which was left without references to it, and thus candidate for destruction at 
some point. But the discarded object never explicitly closed the underlying connection.


Over a period of time, this left an accumulation of (no longer used) connections in the 
"CLOSE_WAIT" state (closed by the remote host side, but not by the webapp side), which 
just sat there until a GC happened, at which time the destruction of these objects really 
happened, and some implicit close was done at the OS level, which eliminated these pending 
underlying CLOSE_WAIT connections.
And since the available heap was quite large, it took a long time before a GC happened, 
which allowed such CLOSE_WAIT connections to accumulate in the hundreds or thousands 
before being "recycled".
Until a certain number was reached, and then the host became all but unreachable and very 
slow.
That was a long time ago, and thus a lot of Java versions and Linux versions ago, so maybe 
something happened since then to avoid such a situation.

But maybe also, you are suffering of some similar phenomenon.
You could try to use netstat some more, and when you are having the problem, you should 
count at ALL the TCP connections, including the ones in CLOSE_WAIT, and just check if you 
do not have an obscene number of them in total.  There is definitely some limit number 
past which the OS starts acting funny.


(Note : unlike for TIME_WAIT e.g., there is no time limit for a connection in the 
CLOSE_WAIT state; it will stay in that state as long as the client side has not explicitly 
closed it, in some kind of zombie half-life)
See e.g. : 
https://users.cs.northwestern.edu/~agupta/cs340/project2/TCPIP_State_Transition_Diagram.pdf




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



Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?

2020-03-27 Thread tomcat/perl

On 27.03.2020 14:27, André Warnier (tomcat/perl) wrote:

On 26.03.2020 20:42, Eric Robinson wrote:

-Original Message-
From: Olaf Kock 
Sent: Thursday, March 26, 2020 2:06 PM
To: users@tomcat.apache.org
Subject: Re: Does Tomcat/Java get around the problem of 64K maximum
client source ports?

Hi Eric,

On 26.03.20 18:58, Eric Robinson wrote:

Greetings,

Many people say the maximum number of client ports is 64K. However,

TCP connections only require unique sockets, which are defined as...


local_IP:local_port -> remote_ip:remote_port

Theoretically, it is possible for a client process to keep using the same local

source port, as long as the connections are to a unique destinations. For
example on a local machine, the following connections should be possible...


192.168.5.100:1400 -> 192.168.5.200:3306
192.168.5.100:1400 -> 192.168.5.201:3306
192.168.5.100:1400 -> 192.168.5.202:3306
192.168.5.100:1400 -> 192.168.5.203:3306

I've seen this demonstrated successfully here:

https://serverfault.com/questions/326819/does-the-tcp-source-port-have
-to-be-unique-per-host

As someone on that page pointed out, while it is possible, it does not

commonly occur in practice "because most TCP APIs don't provide a way to
create more than one connection with the same source port, unless they
have different source IP addresses." This leads to the 64K maximum client
port range, but it is really a limitation of the APIs, not TCP.


So how does tomcat handle things? Is it limited to a maximum 64K client

source ports, or is it 64K per destination, as it should be?

To be honest, I can't remember to have seen a web- or application server
that accepts 64K concurrent connections at all, let alone to a single client.

I can't come up with any reason to do so, I'd assume that there's a DOS attack
if I get 100 concurrent incoming connections from a single IP, and a
programming error if the server sets up more than 1K outgoing connections

Maybe I'm missing the obvious, or have only administered meaningless
installations, but I fail to see the real world relevance of this question.




I don't blame you for being puzzled, but this not about tomcat accepting connections. 
It's about tomcat acting as the client, where MySQL is the server. I'm referring to 
client connections from tomcat to MySQL. We have about 1800 instances of tomcat running. 
This question comes up once in a while when tomcat can't connect to MySQL. Trust me, it 
can be an issue.


--Eric



The question is : is there even any Java API (method) (or even OS API) which allows a 
client to open a (client, non-LISTEN) socket AND specify the client IP address and/or port ?


I mean, if there is none, then the question may be interesting in the absolute, but 
ultimately pointless.


I believe that the IP address of client packets, will be determined by which /route/ the 
OS determines that the target server address can be reached (which will determine through 
which network interface the packets "go out", which will determine the sender IP address 
inserted in the packets). I don't think that the application-level software (here a java 
webapp) can determine this in advance.
And the client port will be decided by the OS-level TCP stack, in function of which ones 
are not yet in use (which a java webapp can also not determine in advance).


Example of creating a client socket :
Socket echoSocket = new Socket(hostName, portNumber);
The hostname (or IP address of ditto) and port numbers passed as arguments, are the 
IP:port of the server you are connecting /to/, not the ones of the local socket.




Addendum :

https://stackoverflow.com/questions/11129212/tcp-can-two-different-sockets-share-a-port/11129641

From which I gather that, although it may be possible (in some languages or using some 
API) to open several client connections (to different target IP/port) using the same local 
port number, you may still have other issues when doing this :
- the host's TCP/IP stack has to keep track of all the simultaneous connections, and if 
the list gets very large, this may become very resource-intensive

- there may be a limit at the OS level, to how many sockets are allowed at the 
same time
- to each connection, corresponds some kind of a "file descriptor". There may be limits, 
at the process level (in this case the JVM running tomcat), or even at the host level, to 
how many of those may be in use at any one time
(So if you were running on a host one JVM for a tomcat instance, it would compete with 
other processes running on the same host and also using file descriptors)


It seems also thus possible that the reason why you are running against a problem not 
being able to make additional connections to a MySql server, is not necessarily the usage 
of all 64K port numbers, but one of the other limitations above.


-
To unsubscribe, e-mail: users-unsubscr

Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?

2020-03-27 Thread tomcat/perl

On 26.03.2020 20:42, Eric Robinson wrote:

-Original Message-
From: Olaf Kock 
Sent: Thursday, March 26, 2020 2:06 PM
To: users@tomcat.apache.org
Subject: Re: Does Tomcat/Java get around the problem of 64K maximum
client source ports?

Hi Eric,

On 26.03.20 18:58, Eric Robinson wrote:

Greetings,

Many people say the maximum number of client ports is 64K. However,

TCP connections only require unique sockets, which are defined as...


local_IP:local_port -> remote_ip:remote_port

Theoretically, it is possible for a client process to keep using the same local

source port, as long as the connections are to a unique destinations. For
example on a local machine, the following connections should be possible...


192.168.5.100:1400 -> 192.168.5.200:3306
192.168.5.100:1400 -> 192.168.5.201:3306
192.168.5.100:1400 -> 192.168.5.202:3306
192.168.5.100:1400 -> 192.168.5.203:3306

I've seen this demonstrated successfully here:

https://serverfault.com/questions/326819/does-the-tcp-source-port-have
-to-be-unique-per-host

As someone on that page pointed out, while it is possible, it does not

commonly occur in practice "because most TCP APIs don't provide a way to
create more than one connection with the same source port, unless they
have different source IP addresses." This leads to the 64K maximum client
port range, but it is really a limitation of the APIs, not TCP.


So how does tomcat handle things? Is it limited to a maximum 64K client

source ports, or is it 64K per destination, as it should be?

To be honest, I can't remember to have seen a web- or application server
that accepts 64K concurrent connections at all, let alone to a single client.

I can't come up with any reason to do so, I'd assume that there's a DOS attack
if I get 100 concurrent incoming connections from a single IP, and a
programming error if the server sets up more than 1K outgoing connections

Maybe I'm missing the obvious, or have only administered meaningless
installations, but I fail to see the real world relevance of this question.




I don't blame you for being puzzled, but this not about tomcat accepting 
connections. It's about tomcat acting as the client, where MySQL is the server. 
I'm referring to client connections from tomcat to MySQL. We have about 1800 
instances of tomcat running. This question comes up once in a while when tomcat 
can't connect to MySQL. Trust me, it can be an issue.

--Eric



The question is : is there even any Java API (method) (or even OS API) which allows a 
client to open a (client, non-LISTEN) socket AND specify the client IP address and/or port ?


I mean, if there is none, then the question may be interesting in the absolute, but 
ultimately pointless.


I believe that the IP address of client packets, will be determined by which /route/ the 
OS determines that the target server address can be reached (which will determine through 
which network interface the packets "go out", which will determine the sender IP address 
inserted in the packets). I don't think that the application-level software (here a java 
webapp) can determine this in advance.
And the client port will be decided by the OS-level TCP stack, in function of which ones 
are not yet in use (which a java webapp can also not determine in advance).


Example of creating a client socket :
Socket echoSocket = new Socket(hostName, portNumber);
The hostname (or IP address of ditto) and port numbers passed as arguments, are the 
IP:port of the server you are connecting /to/, not the ones of the local socket.


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



gostCat patch

2020-03-23 Thread tomcat/perl

Hello tomcat developers.

Re :

current : 
https://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations

quote
secretRequired  

If this attribute is true, the AJP Connector will only start if the secret attribute is 
configured with a non-null, non-zero length value. This attribute only controls whether 
the secret attribute is required to be specified for the AJP Connector to start. It does 
not control whether workers are required to provide the secret. The default value is true. 
This attribute should only be set to false when the Connector is used on a trusted network.

unquote

The above new feature/default has been creating a lot of issues, particularly for 
sysadmins, who upgrade to what looks like a minor version level, and find their 
front-end/back-end configurations not working anymore.

(Because previously, they did not specify this attribute at all, which defaulted to 
"false").

In many cases, this will happen even though the front-end httpd (or IIS) and the back-end 
(tomcat) are in fact running on the same host (*), and thus using the loopback interface 
to communicate (which also fits well with the new default for "address", which is the 
loopback address).


To avoid such surprises for sysadmins, how about the following suggested change, to the 
documentation and to the underlying code :


quote
secretRequired  

If this attribute is true, the AJP Connector will only start if the secret attribute is 
configured with a non-null, non-zero length value. This attribute only controls whether 
the secret attribute is required to be specified for the AJP Connector as they did 
previouslyto start. It does not control whether workers are required to provide the 
secret. This attribute should only be set to false when the Connector is used on a trusted 
network. In consequence and as a hint :
The *default* of this attribute is "false", when the "address" attribute is explicitly set 
to "127.0.0.1" or "::1", or when it defaults to the loopback address.
The *default* of this attribute is "true", when the "address" attribute is set to any 
other IP address.

unquote

The point is to make sure that existing configurations, which often concern a front-end 
and a back-end running on the same host, and which often do not contain an explicit 
"secretRequired" AJP Connector attribute, would default to working as they did before, but 
*only if* the connection is deemed secure anyway, because it is local.
I believe that this alone would already greatly reduce the "stress" caused by this 
security-related configuration change.



(*) I currently manage about 30 Apache httpd / tomcat combinations, and in all of them but 
one, they are on the same host.  And from a historical perspective, I believe that is true 
for the majority of httpd/tomcat installations except large load-balancing configurations.




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



Re: AW: AW: AW: AJP Connector issue

2020-03-20 Thread tomcat/perl

Hi Florian.

The log below shows clearly "The AJP Connector is configured with 
secretRequired="true"".
This probably comes from the fact that in your AJP Connector configuration, you 
either
- have an explicit secretRequired="true" attribute
or
- you do not mention this attribute, and it defaults to "true"

To get the previous behaviour (without secret), you now *must* specify : 
secretRequired="false".
This is one of the changes in the latest tomcat versions compared to the previous one, and 
this was motivated by security reasons.

So I doubt that there is any chance for that change to be reversed.


On 20.03.2020 13:49, Fritze, Florian wrote:

Just to make it clear what from my opinion the problem is:

SCHWERWIEGEND [main] org.apache.catalina.core.StandardService.startInternal 
Failed to start connector [Connector[AJP/1.3-8011]]
org.apache.catalina.LifecycleException: Der Start des 
Protokoll-Handlers ist fehlgeschlagen
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
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.
at 
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
    ... 12 more

This new "secretRequired" attribute prevents the Tomcat from starting 
flawlessly. It was first introduced with the Ghostcat release.
So this is a wish from me to the Tomcat developers: Please set this new 
attribute not mandatory but optional. So that I can run the newest Tomcat 
without this attribute which I do now with the pre-Ghostcat releases.

Have a nice weekend
Florian Fritze

--
Florian Fritze M.A.
Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713
florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de


-Ursprüngliche Nachricht-
Von: André Warnier (tomcat/perl) 
Gesendet: Freitag, 20. März 2020 13:34
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AJP Connector issue

Ok, so it looks like :
- the request is effectively reaching tomcat, and that it is tomcat sending 
back the 403 response.
- the URL is "/", so presumably it is "well-formed" etc.

Furthermore, according to something you wrote below, both Apache httpd and 
tomcat are running on the same Linux host.

This reminds me vaguely of some issue previously (and recently) discussed on 
the list, with some request attributes which tomcat did not like..
But I do not remember ptecisely what the issue was, and it also seems to me 
that this concerned an IIS front-end, not Apache httpd.

Perhaps someone else on the list has a better idea.


Incidentally, it also seems that you are, in httpd, proxying *all* requests to 
tomcat.
Which raises the question of why you have a httpd front-end in the first place.
(But that's a later discussion maybe, let's first see why "/" doesn't work)


On 20.03.2020 11:07, Fritze, Florian wrote:

Here is the additional information:

The error page looks like Tomcat:

HTTP Status 403 – Forbidden

_

Type Status Report

Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine 
Autorisierung.

_

Apache Tomcat/8.5.53

The Apache HTTPD log file says:

- "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0 
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 
Edg/80.0.361.69"

- "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 88

Re: AW: AW: AJP Connector issue

2020-03-20 Thread tomcat/perl

Ok, so it looks like :
- the request is effectively reaching tomcat, and that it is tomcat sending back the 403 
response.

- the URL is "/", so presumably it is "well-formed" etc.

Furthermore, according to something you wrote below, both Apache httpd and tomcat are 
running on the same Linux host.


This reminds me vaguely of some issue previously (and recently) discussed on the list, 
with some request attributes which tomcat did not like..
But I do not remember ptecisely what the issue was, and it also seems to me that this 
concerned an IIS front-end, not Apache httpd.


Perhaps someone else on the list has a better idea.


Incidentally, it also seems that you are, in httpd, proxying *all* requests to 
tomcat.
Which raises the question of why you have a httpd front-end in the first place.
(But that's a later discussion maybe, let's first see why "/" doesn't work)


On 20.03.2020 11:07, Fritze, Florian wrote:

Here is the additional information:

The error page looks like Tomcat:

HTTP Status 403 – Forbidden

   _

Type Status Report

Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine 
Autorisierung.

   _

Apache Tomcat/8.5.53

The Apache HTTPD log file says:

- "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0 
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 
Edg/80.0.361.69"

- "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 885 
"https://dev-fordatis.fraunhofer.de/; "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69"



The Tomcat says:

- - [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 630

- - [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 630



The server on which all is running is:

Linux 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux



There is no new entry in the Apache HTTPD error.log concering these requests.



Help is appreciated

Florian Fritze

--

Florian Fritze M.A.

Fraunhofer-Informationszentrum Raum und Bau IRB

Competence Center Research Services & Open Science

Nobelstr. 12, 70569 Stuttgart, Germany

Telefon +49 711 970-2713

florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de





-Ursprüngliche Nachricht-
Von: André Warnier (tomcat/perl) 
Gesendet: Freitag, 20. März 2020 10:14
An: users@tomcat.apache.org
Betreff: Re: AW: AJP Connector issue



On 20.03.2020 08:23, Fritze, Florian wrote:


Hello Chris,







thanks for the reply. Maybe I am doing something wrong, but setting



secretRequired="false" does not solve my issue. Let me show you what I



did and experience: I added 


redirectPort="8443" secretRequired="false" /> to the Tomcat



configuration and the ajp connector on the Apache HTTPD side connects



to 8011. When I now visit my website I got HTTP Status 403 – Forbidden




And just to make diagnosis a bit quicker : does that 403 error page look like 
an Apache httpd page, or a tomcat page ? (they look quite differemt in style).



Also, can you check both the httpd logs, and the tomcat logs for that request, 
and check what they say ?  (compare by timestamnp and URI)



Also, under what OS does your front-end httpd run ?








I attached also the error page as a screenshot to this mail. This



behaviour exists only sice the Ghostcat fix release (I know that this



has nothing to do with security fix but probably with the release itself).







Thanks in advance



Florian







--



Florian Fritze M.A.



Fraunhofer-Informationszentrum Raum und Bau IRB Competence Center



Research Services & Open Science Nobelstr. 12, 70569 Stuttgart,



Germany Telefon +49 711 970-2713 
florian.fri...@irb.fraunhofer.de<mailto:florian.fri...@irb.fraunhofer.de> |



www.irb.fraunhofer.de<http://www.irb.fraunhofer.de>







-Ursprüngliche Nachricht-



Von: Christopher Schultz 
mailto:ch...@christopherschultz.net>>



Gesendet: Donnerstag, 19. März 2020 20:14



An: users@tomcat.apache.org<mailto:users@tomcat.apache.org>



Betreff: Re: AJP Connector issue







-BEGIN PGP SIGNED MESSAGE-



Hash: SHA256







Florian,







On 3/19/20 07:43, Fritze, Florian wrote:



since the Tomcat release with the Ghostcat security fix (Tomcat



8.5.51) me as an admin have the problem using the



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



connect the Apache HTTPD with the Tomcat running on localhost. The



attribute secretRequired must be set to „true“ or „false“ with



„false“ set the connection is not possible between Tomcat and Apache HTTPD.







When you have set secretRequired="false", it's not possible to



connect? When you tr

Re: AW: AJP Connector issue

2020-03-20 Thread tomcat/perl

On 20.03.2020 08:23, Fritze, Florian wrote:

Hello Chris,

thanks for the reply. Maybe I am doing something wrong, but setting
secretRequired="false" does not solve my issue. Let me show you what I did
and experience: I added  to the Tomcat configuration
and the ajp connector on the Apache HTTPD side connects to 8011. When I now
visit my website I got HTTP Status 403 – Forbidden


And just to make diagnosis a bit quicker : does that 403 error page look like an Apache 
httpd page, or a tomcat page ? (they look quite differemt in style).


Also, can you check both the httpd logs, and the tomcat logs for that request, and check 
what they say ?  (compare by timestamnp and URI)


Also, under what OS does your front-end httpd run ?



I attached also the error page as a screenshot to this mail. This behaviour
exists only sice the Ghostcat fix release (I know that this has nothing to
do with security fix but probably with the release itself).

Thanks in advance
Florian

--
Florian Fritze M.A.
Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713
florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de

-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Donnerstag, 19. März 2020 20:14
An: users@tomcat.apache.org
Betreff: Re: AJP Connector issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Florian,

On 3/19/20 07:43, Fritze, Florian wrote:

since the Tomcat release with the Ghostcat security fix (Tomcat
8.5.51) me as an admin have the problem using the
https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to
connect the Apache HTTPD with the Tomcat running on localhost. The
attribute secretRequired must be set to „true“ or „false“ with „false“
set the connection is not possible between Tomcat and Apache HTTPD.


When you have set secretRequired="false", it's not possible to connect? When
you try to connect, what DOES happen?


With „true“ the Apache development is not ready in the current version
to work with the „secret“ attribute. Only the next version of Apache
2.4 supports this attribute.

Correct. Support for secret= in mod_proxy_ajp was evidently never really a
priority for anybody until now.


So I want to use the newest Tomcat version and an AJP connector but
after the Ghostcat fix release there is this attribute which does not
work in my configuration.

Are there any suggestions or solutions available that you can deliver
me (links or documentation, etc.)


secretRequired="false" should be all you need.

Of course, to be truly secure, you need to make sure that not just anybody
can make requests through your AJP interface. Have you secured that
interface from potential evildoers?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxHsACgkQHPApP6U8
pFjf7Q/+Ixbc10KYI07Wb1pdzQajVtw88BcfSZ3dfam2Q9aj2IhZJD5GUTzszAGC
bs6eySKEh5vqaHq+oy2ZOuv2f1xxukPQ3/XfmIEUb83G7QScwlMf0r5dth9uslcq
cUgHFkpGhSQghB2yhZSzKMzF7gjRY9QI0S5EpEHTQ45CUvREWr4GRyLndkjTbu2C
rhdB+8ud4iErWJe1Er0NEqOgoVL8Ceed4BGRYzoT7+lN1dRE4MFIn8ALdVzAvo4L
9ZIm+zawSkx7jUTAGDi4wHd2KrewR9kqJybovZaACx/yc6IF1Sv+DaWlTUDdabE2
qrSl45mA4EdLCeH1wfbZ62IhErbxvLahygAwgYSeMfhv02vzBbmn8bXY4yg359ln
aO2AV3xNbxFrF56XatRGIJ+3/ETh2oIv0PLnJEr8xc3CcwdJ+rn8c9i84ZZLnHb6
iTl+Gx9pCUbtH0qCILzLzj7Js9yl13o9AVu3UQ9UxY9BNxkFiKKBe4YfGUev2iiB
Vx1Zw6S6/ByjhUpzaSEciSYCkr+pR61iOJpCN9B3tnpv4cRgkqwPWEPgMFDtvFT9
ciwpDuN+O2YPPE0Z39tSy64Ge2QWyPkvb8hVZUEZGVMRmQ1W5LhDJhNxECklxKOh
sZPFkji5aVOxj6TT5vwqQDov+FyU2pV5/HRD4fe/vr8vdKj+vec=
=CYi0
-END PGP SIGNATURE-

-
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: I wish I could forward all requests completely to another server.

2020-03-19 Thread tomcat/perl

On 19.03.2020 04:18, HeeGu Lee wrote:

I was tasked with writing a web application that needs to forward a http
request to each server after checking certain headers.
Of course I can use a library like apache http client to reconstruct and
send the data.
But if you think about it, this is a very unreasonable and bad way.


No, it is pretty much the only way that makes sense. Well, at least if you want to do this 
with tomcat.


First : there is no code in tomcat that does any kind of "proxy/forwarding" function, nor 
(to my knowledge) any plan to add such code.

See the first phrase of the tomcat on-line documentation, at 
http://tomcat.apache.org/

So any such function must be implemented by a web application (servlet) running under 
tomcat, and I guess that whoever asked you to create such a servlet knew this, and that's 
why they asked you to do it this way.


You could also search for already-existing software which does this, for 
example here :
https://cwiki.apache.org/confluence/display/tomcat/ServletProxy
or here :
https://sourceforge.net/projects/j2ep/




Suppose you need to forward a request that uploads a 100 mega file.
To forward this, once the servlet receives it as an object, the server
memory is already reduced.
Couldn't Servlet Engine check and pass only a few headers and pass it in
stream format?


See above. If you create yourself a "proxy servlet", you are allowed to do in it what you 
want. As soon as tomcat receives the original request, its headers are available to your 
servlet for examination, and you can start a connection to the target back-end server.
You can then read the request content body in any way you want, and send it to the target 
back-end in any way you want.  The only thing is, you can read ("consume") the request 
body only once, so if you need to "distribute" the same request to several back-ends, you 
will have to do some local buffering anyway.



Even if it is not the above example, I think the servlet may have the
ability to have it in a raw state or to return it, like the request strings
sent to telnet.
I think it would be great if this could be supported by the servlet engine
itself.


As indicated by the tomcat description, it is not really tomcat's purpose to be a reverse 
proxy.  There are other webservers which already contain proxying code (like Apache 
httpd), and which may be a better starting point to do this.





Thank you for reading!




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



Re: AJP Connector issue

2020-03-19 Thread tomcat/perl

On 19.03.2020 12:43, Fritze, Florian wrote:

Dear Tomcat users,

since the Tomcat release with the Ghostcat security fix (Tomcat 8.5.51) me as an admin 
have the problem using the https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module 
to connect the Apache HTTPD with the Tomcat running on localhost. The attribute 
secretRequired must be set to „true“ or „false“ with „false“ set the connection is not 
possible between Tomcat and Apache HTTPD. With „true“ the Apache development is not ready 
in the current version to work with the „secret“ attribute. Only the next version of 
Apache 2.4 supports this attribute.


So I want to use the newest Tomcat version and an AJP connector but after the Ghostcat fix 
release there is this attribute which does not work in my configuration.


Are there any suggestions or solutions available that you can deliver me (links or 
documentation, etc.)



Hello.
It all depends on your configuration, and how your front-end Apache httpd server(s) 
connect to your back-end tomcat server(s).

For example :
- if all your pairs of httpd server/tomcat server are running on the same host, then you 
do not really have a security issue, and adding a secret will not really bring any 
additional security
- if all your pairs of httpd server/tomcat server are communicating only over an internal 
(presumed to be fairly safe) network, then you do have a limited security issue (limited 
by how "safe" your internal network really is), and a secret may help a bit in reducing 
this already limited security issue
- if you have pairs of httpd/tomcat which communicate over a public network, then you do 
have a security issue, and adding a secret will help, but it is not going to make that 
security issue really disappear (*).


But if you want to add a secret anyway, then it depends on how httpd communicates with its 
corresponding tomcat, and there are 2 options :

- using the httpd mod_proxy_ajp module
or
- using the httpd mod_jk module

As I understand from your message, the current mod_proxy_ajp module released with the 
current httpd 2.4, does not support that "secret" yet.
But the currently available mod_jk module does support that option, and the current mod_jk 
module is compatible with any httpd 2.4 version.

And, functionally, mod_proxy_ajp and mod_jk can do the same things.
It is just the setup and configuration (at the httpd level) that is somewhat different 
between the two. (there is no difference at the tomcat level).


So if you are currently using mod_proxy_ajp (**), then if you want to implement this 
"secret" option, you would have to change your httpd configuration, to use mod_jk instead 
of mod_proxy_ajp (temporarily, until the appropriate version of mod_proxy_ajp is released).


(*) the secret, if correctly implemented, will block any other host than your own hosts 
from connecting to the tomcat AJP Connector, and thus from "abusing" your tomcats by 
sending them invalid or malicious requests.
But it would not block someone from intercepting the traffic between your httpds and your 
tomcats and reading it, because the AJP protocol is not encrypted, and because there is no 
implementation available that makes this traffic be encrypted.


(**) If you are currently using mod_proxy_ajp, then it is also likely that you are not 
using the option whereby httpd can do the user authentication, and then pass the 
authenticated user-id along to tomcat, for tomcat to use it.

That means that you are already avoiding one possible security issue.


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



Re: [External] Re: Starting up Tomcat 8

2020-03-18 Thread tomcat/perl

On 17.03.2020 21:43, Maxfield, Rebecca A wrote:

Ah, some problems are arising because, I suppose, the startup process wants to 
create or touch something in ../logs and that's now all the way over in 
/var/lib/tomcat8. How do I move on from here?


Try (as root) : service tomcat8 start  (or restart or stop ..)

As mentioned before, the Debian package is assembled in such a way that it will function 
in the same way as other "services" in the Debian environment, log in the same general 
place etc..

The above command in fact runs the shell script at /etc/init.d/tomcat8.
This script sets a number of variables before calling tomcat's startup.sh, changes to the 
approriate directory etc..


If you want a tomcat8 which is installed in a single directory, and which reacts in the 
"canonical" way as explained on the tomcat website, then you would have to de-install the 
Debian tomcat8 package, and install tomcat8 as per the tomcat website.

But that's probably, in your case, more work than necessary.
You just want to run some tomcat applications (webapps), right ?




On 3/17/20, 4:40 PM, "Maxfield, Rebecca A"  wrote:

 I see it now in /usr/share/tomcat8/bin, thank you! Can I just run 
startup.sh from there or is that not right?
 
 On 3/17/20, 4:37 PM, "André Warnier (tomcat/perl)"  wrote:
 
 On 17.03.2020 21:18, Maxfield, Rebecca A wrote:

 > Both are Linux. The new is Debian, the old ??
     
 On a Debian Linux system, tomcat 8 installed via the standard Debian package manager

 results in some files appearing in the following directories (and 
maybe others)
 - /etc/tomcat8
 - /usr/share/tomcat8
 - /var/lib/tomcat8
 - /var/log/tomcat8
 - .. ?
 Some of the entries in these directories are links pointing somewhere 
else. It is
 sometimes a bit difficult to follow. But it works, and it allows 
tomcat to be managed
 using the Debian usual commands for starting/stopping services, 
install updates etc..
 
 Use this command to see a full list of the directories/files used :

 dpkg --listfiles tomcat8
 
 (Note : this gives a list of directories/files initially reated or installed by the

 standard Debian tomcat8 package. But it does not include anything 
created/installed later
 on maybe to "customise" tomcat8 on that machine).
 
     >

 > On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)"  
wrote:
 >
 >  On 17.03.2020 19:52, Maxfield, Rebecca A wrote:
 >  > Hello,
     >  >
 >  > I manage a project that currently runs on Tomcat 7 but is 
migrating to a new server where Tomcat 8 was installed by the server admin. When I 
navigate to the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh 
or similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does 
this imply that it was not installed completely/correctly?
 >  >
 >  What is the platform (OS) of the new server ? (and the old one)
 >  Maybe it was installed using a package provided by the 
platform, in (eminently variable)
 >  other directories.
 >
 >
 >
 >  
-
 >  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 >  For additional commands, e-mail: users-h...@tomcat.apache.org
 >
 >
 >
 >
 >
 >
 >  › This email was sent from outside of Providence College
 >  › Do not click any suspicious links or open any attachments 
that you are not expecting
 >  › Never send any sensitive or financial information (Including 
passwords, social security numbers, credit card numbers, and gift cards) via email
 >
 >
 >
 > -
 > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 > For additional commands, e-mail: users-h...@tomcat.apache.org
 >
 
 
 -

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

 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.

Re: [External] Re: Starting up Tomcat 8

2020-03-17 Thread tomcat/perl

On 17.03.2020 21:18, Maxfield, Rebecca A wrote:

Both are Linux. The new is Debian, the old ??


On a Debian Linux system, tomcat 8 installed via the standard Debian package manager 
results in some files appearing in the following directories (and maybe others)

- /etc/tomcat8
- /usr/share/tomcat8
- /var/lib/tomcat8
- /var/log/tomcat8
- .. ?
Some of the entries in these directories are links pointing somewhere else. It is 
sometimes a bit difficult to follow. But it works, and it allows tomcat to be managed 
using the Debian usual commands for starting/stopping services, install updates etc..


Use this command to see a full list of the directories/files used :
dpkg --listfiles tomcat8

(Note : this gives a list of directories/files initially reated or installed by the 
standard Debian tomcat8 package. But it does not include anything created/installed later 
on maybe to "customise" tomcat8 on that machine).




On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)"  wrote:

 On 17.03.2020 19:52, Maxfield, Rebecca A wrote:
 > Hello,
 >
 > I manage a project that currently runs on Tomcat 7 but is migrating to a 
new server where Tomcat 8 was installed by the server admin. When I navigate to 
the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or 
similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does 
this imply that it was not installed completely/correctly?
 >
 What is the platform (OS) of the new server ? (and the old one)
 Maybe it was installed using a package provided by the platform, in 
(eminently variable)
 other directories.
 
 
 
 -

 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 
 
 
 
 
 › This email was sent from outside of Providence College

 › Do not click any suspicious links or open any attachments that you are 
not expecting
 › Never send any sensitive or financial information (Including passwords, 
social security numbers, credit card numbers, and gift cards) via email
 



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




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



Re: Starting up Tomcat 8

2020-03-17 Thread tomcat/perl

On 17.03.2020 19:52, Maxfield, Rebecca A wrote:

Hello,

I manage a project that currently runs on Tomcat 7 but is migrating to a new 
server where Tomcat 8 was installed by the server admin. When I navigate to the 
/var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or 
similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does 
this imply that it was not installed completely/correctly?


What is the platform (OS) of the new server ? (and the old one)
Maybe it was installed using a package provided by the platform, in (eminently variable) 
other directories.




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



Re: OpenId with apache and tomcat

2020-03-13 Thread tomcat/perl

On 13.03.2020 17:53, Stephane Passignat wrote:

Hi,

Actually I have Apache2 operating as proxy and authenticate layer (HTTP
Form and HTTP Basic), in front of several Tomcat instances and webapps.
Apache pushes the userId to tomcat through AJP.
On tomcat side, the webapp has a Basic login-module in web.xml.

I'm quite satisfied of the result, authentication and authorization are
out of the application scope. The deployment and maintenance of
application is super easy. The sensitive maintenance of authentication
is made by a dedicated team...

I wish to improve that adding OpenId Authentication, keeping apache as
authentication layer with an openid connector, but the one I saw
doesn't seems to be used a lot and is not available as precompiled for
my os...


Actually, mod_auth_openidc (which I have not used myself), available from
(https://github.com/zmartzone/mod_auth_openidc)
at least on the face of it, seems to be fairly complete, well-documented (with examples), 
supported, and regularly worked on.


Considering your current architecture, and considering that OpenID itself (like anything 
to do with OAuth) is quite a nightmare in terms of readable and 
understandable-by-common-mortals documentation, I would think that you might save yourself 
a lot of time by trying it out.
It seems to have its own help forums too, which may help in terms of obtaining or creating 
the appropriate binaries.




I'm looking also at moving authentication at tomcat level with an
openid Realm. It's not ideal because of the large number of
applications are servers do impact and network configuration to change,


Exactly, see above.
I think that mod_auth_openidc would fit right in (and along) with your existing form and 
Basic authentication in Apache httpd. And you would not have to change anything at the 
Tomcat or applications level.


Just make sure to properly secure your AJP connections.
(see quite a few discussions on that topic in the last month, in the archives 
of this list)


...



Does someone have experience in this architecture ? Do you have some
recommendation for Apache Module or Tomcat Realm to use ?



Make sure that you know exactly what *version* of OpenID you need.
As far as I know, the current version is "OpenID Connect", and anything else is obsolete 
and even worse in terms of documentation.




Thanks
Stephane




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



Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31

2020-03-11 Thread tomcat/perl

On 10.03.2020 15:44, Martin Grigorov wrote:

On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 3/10/20 04:43, Martin Grigorov wrote:

We can define custom address like "loopback" for which Tomcat will
bind on both "127.0.0.1" and "::1" depending on the values of
java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I
am not sure whether it is worth it

This is kind of an interesting suggestion, as would maybe supporting
"all" as an alias for both 0.0.0.0 and :: together (the old default
behavior, which is no longer possible with a single ).

Are there any examples of these kinds of things in other products, or
does everyone just manually define two separate connector-like entities?

httpd just does:

   Listen 0.0.0.0
   Listen ::

Which is pretty simple. Tomcat's  configuration is a lot
more verbose and so repeating it is doubly so.



Another option is to make "address" attribute multi valued, e.g.
comma/space separated.



My 2 cent :

Since the changes were necessary, have been made and are presumably there to stay, and 
since this seems to have caused a lot of confusion with a lot of sysadmins, mainly among 
the ones which had a working front-end/back-end configuration, which suddenly stopped 
working when they made a minor version upgrade. And since even so, it seems that when the 
change was made, there was quite an underestimate of the side-effects and the impact this 
would have in the practical reality out there, should there not be a separate addition to 
the documentation, explaining this AJP Connector and its settings "from the ground up", 
starting with the fact that currently, it is basically insecure if used on an open network 
(and that this was not its original purpose).

(At least that's my sysadmin-level understanding of what I've read here so far).

And when talking about changing some Connector attributes, maybe a review should be made 
first, downwards as well as upwards :
- downwards : ultimately a Connector represents a socket (or more than one ?), at the OS 
TCP/IP stack level. Some information from that OS-level socket presumably "filters up" 
through whatever layers there can be between it, and the container level and the Java 
servlets running inside that container. Is that information liklely to be used at the 
application level, and would proposed changes be neutral in that respect ?
- upwards : it seems from the accumulated discussions here, that (for example) to 
implement some of the changes/improvement, users (sysadmins) may have to go as far as 
duplicating the whole Connector tag, to implement the "listen only on localhost" feature 
(but, that this depends both on the underlying OS and on the in-between layer between that 
OS and the Connector). And, if some application software currently "interrogates" the 
Connector to find out about its IP address (or the IP address of the client connected to 
it), what answer would it get if the "address" attribute would become multi-value ? 
/Could/ it even get such an answer, if the underlying socket is not one, but two ?


I don't know the answer to the above questions, and I don't even know whether they really 
are valid questions.  But again, I look at this from a sysadmin configurator point of 
view, without necessarily a deep understanding on the Java finery underlying all this, and 
I'm quite confused and worried that I could inadvertently break some user application and 
not really understand why.


And maybe another underlying question : is it really unthinkable to have an AJP connection 
capable of running under SSL ? (I mean directly, not under some external setup like 
stunnel e.g.)






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



Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31

2020-03-11 Thread tomcat/perl

On 11.03.2020 09:30, Piyush Kumar Nayak wrote:

What's the point of " ipv6v6only" attribute. The doc says :
"If listening on an IPv6 address on a dual stack system, should the connector only 
listen on the IPv6 address? If not specified the default is false and the connector will 
listen on the IPv6 address and the equivalent IPv4 address if present."

So if I set address to "::1" and " ipv6v6only" is left to its default, 
shouldn’t, the connector listen to both the addresses.



I guess it depends on the precise meaning of "on a dual stack system" ..




-Original Message-
From: Martin Grigorov 
Sent: Tuesday, March 10, 2020 8:14 PM
To: Tomcat Users List 
Subject: Re: bind Tomcat to IPv4 and IPv6 loopback, Tomcat 9.0.31

On Tue, Mar 10, 2020 at 3:56 PM Christopher Schultz < 
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 3/10/20 04:43, Martin Grigorov wrote:

We can define custom address like "loopback" for which Tomcat will
bind on both "127.0.0.1" and "::1" depending on the values of
java.net.preferIPv4Stack and java.net.preferIPv6Addresses, but I am
not sure whether it is worth it

This is kind of an interesting suggestion, as would maybe supporting
"all" as an alias for both 0.0.0.0 and :: together (the old default
behavior, which is no longer possible with a single ).

Are there any examples of these kinds of things in other products, or
does everyone just manually define two separate connector-like entities?

httpd just does:

   Listen 0.0.0.0
   Listen ::

Which is pretty simple. Tomcat's  configuration is a lot
more verbose and so repeating it is doubly so.



Another option is to make "address" attribute multi valued, e.g.
comma/space separated.

Martin




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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5nnHEACgkQHPApP6U8
pFirYA/9HvjI2fX//oqTFvmgGXW/7memXkrUkMiQ3JrUhwc5KrSn4CJAamwiqzTr
Lm+CACeEuiMK4qGbQ+NSpfql0k1pb8BUTX7Ut/KW1lsa8t/DY2DU0SNBw3mvnfL1
XoTsAbQgswpoxozZe11ZZyo42O2BCqTcO8Yp2X3K6DUAGvusPl00VMzpYfgsoLCv
ZvxljLPRY5szRfCf7qrXOtPoByxvnKX2coQBIKJ8+MEKIo6ZApNX8OPf2HNGjvPT
/OCRef/+uIXQaGIYOS8OlNxmFLEs/iGPZ2412l0rAA1hArlW4yCe7eDe3RCbiMeH
FKHbqgbTRPNXWTqf3/BqEimcQj6YdXm+k019IDWGS7vhfPkiBci6qbKO9GLVjSct
4R9J++/s5CQp7zC3aM1kS5Paoho+CMevMneD0c6m4lGvM007jX4yr1z3QZxtFzqg
KpcYieJgWGl0pOVw4s5YnngK1WXosb7gyjEN7ktPEE4xdeTk57shceGg1YDDRpyG
n9gtwiXJf1zwUMOq0ttHNNvLdXL+y2Ud7adG5Sjg/5Y3RCP9vAQNdq+CcHS3aLGo
WVfME5zcrSJlpD0arqg5ZNduYMAwgvO1GEnqfFEfEKpPXJNXAzX9YtCm0/ckFMC6
gB7xVv72Ow7kmsftA478+nPCiZTwmkVyLqVoOIr0+OSTn0tiDu0=
=ewrT
-END PGP SIGNATURE-

-
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: Problem with tomcat connector in IIS using tomcat 9.0.31

2020-03-04 Thread 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: issue faced in tomcat 8.5.51

2020-03-02 Thread tomcat/perl

On 02.03.2020 07:38, Rathore, Rajendra wrote:

Hi Calder/Team,

I set the below flag as false but still it will giving the same error.


If you really changed that attribute in the right place, and you restarted tomcat, it is 
quite unlikely that you would have the same error in the log.


But if you really do, could you please copy the latest Connector configuration here, and 
another new extract of the log showing the error ?

(Just copy/paste here please, not in an attachmemnt)



I am using Apache http server(with AJP worker) and tomcat configuration, Is am 
I missing something in configuration, please let me know?

Thanks and Regards,
Rajendra Rathore
9922701491

-Original Message-
From: calder 
Sent: Friday, February 28, 2020 7:41 PM
To: Tomcat Users List 
Subject: Re: issue faced in tomcat 8.5.51

External email from: users-return-269823-rarathore=ptc@tomcat.apache.org

On Fri, Feb 28, 2020, 07:39 Rathore, Rajendra  wrote:


Hi Team,

I am using below configuration in server.xml for tomcat



but I got below exception in start up time



< snip >





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







Please let me know what should I put to fix the issue, it will be very

helpful for me.

I am stuck because of the above issue, we are using Apache and tomcat
for serving the request.

Let me know if anything else required from my side.



-
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: issue faced in tomcat 8.5.51

2020-02-28 Thread tomcat/perl

On 28.02.2020 15:11, calder wrote:

On Fri, Feb 28, 2020, 07:39 Rathore, Rajendra  wrote:


Hi Team,

I am using below configuration in server.xml for tomcat



but I got below exception in start up time



< snip >





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






Please let me know what should I put to fix the issue, it will be very

helpful for me.



Sure, here you go : look carefully at the on-line documentation, in
http://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations

Note, for information : these attributes and values have *changed in 8.5.51*, compared to 
previous tomcat revisions.



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



Re: Error parsing HTTP request header

2020-02-26 Thread tomcat/perl

On 26.02.2020 14:30, dku...@ccilindia.co.in wrote:

Dear Team,

We are getting below error in catelina log while starting the tomcat.

26-Feb-2020 18:57:36.795 INFO [main]
org.apache.catalina.startup.Catalina.start Server startup in 21520 ms
26-Feb-2020 18:57:38.277 INFO [http-nio-443-exec-11]
org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing
HTTP request header
  Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
  java.lang.IllegalArgumentException: Invalid character found in the
request target. The valid characters are defined in RFC 7230 and RFC 3986
 at
org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:283)
 at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1017)
 at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1524)
 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1480)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Thread.java:748)

Will this impact any performance of our tomcat.



It is not quite clear what you mean by that question.

Origin of the above :
- a HTTP client sent an invalid HTTP request to your tomcat
- tomcat caught this, refused the request, and warned you of it by writing a detailed 
error message to the logfile
- tomcat also tells you that if there are any further errors of the same type, you will 
only see them in the logfile, if you turn the general log level of tomcat to "debug" 
(which produces *a lot* of messages). That is tomcat's way of saving resources, in case 
there are many more requests of that kind.


Will this impact the performance of tomcat ?

Well, of course, if your tomcat continues to receive a lot of such invalid requests all 
the time, that will use some of the processing time of the tomcat host, even to return an 
error to the client.  But this has nothing to do with your tomcat per se or its 
configuration, it has to do with bad or malicious clients out there, which send invalid 
requests to your server, and it would be the same with any webserver.
If you want to filter out such requests before they arrive to tomcat, you will have to put 
in front of tomcat some specialised filtering device which is optimised to do that kind of 
thing.





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



Re: [OT] At wits end: Difficulties with IIS ISAPI connector andTomcat

2020-02-26 Thread tomcat/perl

Hi.
I think that we are getting complicated and confusing here.
A picture is worth a thousand words, so a little ASCII graphic art may help 
clarifying things.

browser <-(1)-> IIS + proxy <-(2)-> tomcat <-> application

- connection (1) can be HTTP or HTTPS (admin choice)
- connection (2) can be HTTP, HTTPS, or AJP (admin choice)

To simplify, let's say that connection (1) is always HTTPS.
In principle, even if connection (1) is HTTPS, IIS should be able to "proxy" the requests 
to Tomcat over HTTP,HTTPS, or AJP, depending on the configuration of

a) IIS itself
b) the proxy add-on module inside IIS

A) If you want to do this :
browser <-(HTTPS)-> IIS + proxy <-(AJP)-> tomcat <-> application
then :
- the proxy module to use in IIS is isapi_redirector
- the target Connector/port in tomcat is an AJP connector
- AJP is a protocol similar to HTTP/HTTPS, but it is different from them both, and it does 
not support encryption


B) If you want to do this :
browser <-(HTTPS)-> IIS + proxy <-(HTTP)-> tomcat <-> application
then :
- the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy 
module within IIS. I do not know which one or how to configure it, because I am not an IIS 
specialist. But it is probably a built-in module in the standard IIS.

- the target Connector/port in tomcat is an HTTP Connector
- HTTP is not encrypted, but it does not matter very much here, because the connection is 
only within the same host.


C) If you want to do this :
browser <-(HTTPS)-> IIS + proxy <-(HTTPS)-> tomcat <-> application
then :
- the proxy module to use in IIS is NOT isapi_redirector, it will be some other proxy 
module within IIS. same comment as for (B)

- the target Connector/port in tomcat is an HTTPS Connector
- HTTPS is encrypted, but this is taken care of by the proxy module on the IIS side, and 
the HTTPS Connector on the Tomcat side.


All 3 solutions above are completely equivalent in terms of forwarding (some) requests to 
tomcat.
But maybe something to insist on : only solution (A) above requires isapi_redirector. 
workers.properties is something which is /only/ used by isapi_redirector, so if you choose 
solutions (B) or (C), you do not need that file at all.


And I do not know if it possible (but presumably it is) to configure IIS to do (B). But 
that is something for which in principle we cannot help you on this list, because we are 
not IIS specialists here.


Does this make things clearer ?



On 26.02.2020 00:17, Ellen Meiselman wrote:

Hi Chris,



Does this mean that incoming connections require SSL or aso outgoing
(e.g. proxy) connections? I'm super ignorant of IIS configuration.
Incoming connections require SSL or will be upgraded to SSL. So if you
type in http, it will change to https.



Right now because I do not have SSL set as required, I can type in http and
it stays http. At that point, it starts working  - I no longer get the 403
from Tomcat.

My recommendation would be to take this opportunity to switch to HTTPS

and dump AJP.


OK, I am willing to try - so to do that, would this be the procedure?
1. Set up certificates in Tomcat (big black box for me, but I'll try to
figure it out)
2. Change the worker.worker1.type to HTTPS
3. Change the worker.worker1.port to 8443
Anything else?

Ellen






On Tue, Feb 25, 2020 at 5:47 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ellen,

Oops pressed SEND before I was done...

On 2/25/20 16:47, Ellen Meiselman wrote:

So it turned out that the logs were mostly set at FINE already, so
Johann’s suggestion was already done.

But I think I now know where the problem lies. Secure IIS request

to > non-secire AJP.


I don’t think this was a problem on the other servers before but
the security has probably been tightened, and it just doesn’t
produce an error - it just won’t allow it.

I have had IIS set to require SSL


Does this mean that incoming connections require SSL or aso outgoing
(e.g. proxy) connections? I'm super ignorant of IIS configuration.


but I turned it off to test and it actually worked all the way
through to the simple.html file. so it’s some sort of policy about
downgrading - which seems quite rational in retrospect. For
example, this HTTP address does work.

http://my.servers.domain.com/exposedApplication/simple.html

I never tried it because I knew I had set SSL to required.
Sometimes you make assumptions that block progress.

This HTTPS address does not work - I get the 403 from tomcat.
https://my.servers.domain.com/exposedApplication/simple.html

So  - if this makes sense to any of you, please tell me roughly
what I need to do to make the AJP requests as secure as the port 80
requests.


Um...


I know keystores and .pem files are involved, but please give me
the big picture - what port does AJP need to run on, and where do
I go to find out how to 

Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

2020-02-25 Thread tomcat/perl

The workers.properties below look good to me at first sight.

Just to eliminate something, could you try the following changes :

1) workers.properties :
remove the line
> worker.worker1.secret="mySecret".

2) AJP Connector in tomcat :



then restart tomcat and IIS.
What's happening then ?

Note : this is something new in tomcat 8.5.51 compared to 8.5.50 and earlier.
Before, by default, the "secret" was disabled. Since 8.5.51, by default, the secret is 
enabled, and you have to disable it explicitly if you don't want it (as I did above).


With the settings above, we are just trying to get back to a configuration without secret, 
to check if that works in your case.
As indicated in the documentation 
(http://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html#Standard_Implementations) you can 
do that in your case, because the communication between IIS and Tomcat is fairly secure, 
since it happens all within the same host.



On 25.02.2020 18:06, Ellen Meiselman wrote:

Yes, everything is on the same server.

workers.properties:
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=127.0.0.1
worker.worker1.port=8009
worker.worker1.secret="mySecret".

On Tue, Feb 25, 2020 at 11:27 AM 
wrote:


-Original Message-
From: Ellen Meiselman 
Sent: Tuesday, February 25, 2020 10:01 AM
To: Tomcat Users List 
Subject: Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat


Hi,



I've been testing, and so far, there is no change in the behavior. I am

still getting the same tomcat->based 403 error.


Based on what you said above...

secretRequired="true" (which is the default, so it can be removed)
secret="xxx"




...I removed secretRequired="true" and left secret. So the connector

definition now looks like this:






I'm assuming that your web-front-end is on the same server as your Tomcat
instance, based on you having the address set to 127.0.0.1, correct? What
do you have in your workers.properties file?






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



Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

2020-02-25 Thread tomcat/perl

On 25.02.2020 17:26, jonmcalexan...@wellsfargo.com.INVALID wrote:

-Original Message-
From: Ellen Meiselman 
Sent: Tuesday, February 25, 2020 10:01 AM
To: Tomcat Users List 
Subject: Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat


Hi,



I've been testing, and so far, there is no change in the behavior. I am still 
getting the same tomcat->based 403 error.



Based on what you said above...

secretRequired="true" (which is the default, so it can be removed)
secret="xxx"




...I removed secretRequired="true" and left secret. So the connector definition 
now looks like this:





I'm assuming that your web-front-end is on the same server as your Tomcat 
instance, based on you having the address set to 127.0.0.1, correct? What do 
you have in your workers.properties file?


addendum : .. on the IIS side of things.
There should be the same "secret" there.


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



Re: At wits end: Difficulties with IIS ISAPI connector and Tomcat

2020-02-24 Thread tomcat/perl

On 24.02.2020 22:04, Christopher Schultz wrote:

With 8.5.51, requiredSecret is renamed "secret" but "requiredSecret"
is still an alias of the same configuration property. If #2 happens
after #1 above, then your actual secret will be the literal string
"true" (oops).

We apologize for this confusion. We are trying to clarify things and
make them more secure.


Nobody is saying that the new configuration and attributes are not better, from a security 
point of view. The latest on-line documentation, when taken in isolation, is also pretty 
clear and understandable. So people installing tomcat for the first time should have no 
problem.


But I think that quite a few recent posts show that these changes could have been made a 
bit more visible for people who have running tomcats, and are just updating from one minor 
version to the next minor version.
Even the on-line documentation for the Connector, shows the current attributes and 
defaults, but without any mention that they have just changed compared to the previous 
minor version. That has apparently caught a lot of people unaware.


Now how to make this more noticeable, without also alerting the bad guys about the 
pre-existing vulnerabilities, is probably not so easy..


How about adding a note on top of the migration guide pages, saying : "If you are just 
updating from 8.5.50 or lower, to 8.5.51 or higher, you *really* should look at the AJP 
Connector attributes again".


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



Re: Novice Tomcat Admin Question - Filtering log output

2020-02-21 Thread tomcat/perl

On 21.02.2020 18:49, Darryl Philip Baker wrote:

On 2/21/20, 11:36 AM, "Christopher Schultz"  
wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 Darryl,
 
 On 2/21/20 12:15, Darryl Philip Baker wrote:

 > I have taken over the administration of several Tomcat instances.
 > A number of these are load balanced using an F5 appliance.  The
 > org.apache.catalina.values.AccessLogValve log file is filled with
 > the F5 polls to see if the application is alive. Under almost all
 > circumstances these are useless, I would like to stop logging just
 > these requests.
 Dumb question: why bother removing them?

Not so dumb a question, I have 2 reasons. First when looking at the raw file on 
the server these poles from the load balancers make it hard to find the useful 
entries. The second reason is we use Splunk as a log aggregator. In Splunk it 
is easy to filter these out when looking at the log but having all these almost 
useless messages significantly adds to the activity of the Splunk forwarder on 
these systems.



Apart from everything else (I had a few dumb questions/remarks of my own),
See : http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve
attribute : conditionUnless
So you could use this, along with a Filter which applies only to requests with URI 
"/MySite/isAlive.jsp" and sets an attribute "junk" for these; and bingo! they would not be 
logged anymore.


This page even seems to show how you could do that without a Filter, directly in your own 
"isAlive.jsp" :

https://www.roseindia.net/jsp/requestsetattribute.shtml
(No guarantee though, I'm not really the expert here)


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



Re: FW: Apache Tomcat versions and proof of support

2020-02-21 Thread tomcat/perl

Hi.

Maybe you could start by looking at this page :
http://tomcat.apache.org/index.html
and this one :
http://tomcat.apache.org/whichversion.html
(including the comments after the table)

Tomcat is open-source (and free) software, developed, distributed and supported 
by volunteers.
Depending on which operating system platform you are using, the version of tomcat that you 
are using may be supported by the OS vendor.

There are also commercial organisations which offer (paying) support for tomcat.

Otherwise, tomcat support is essentially via this very list, which is also manned by 
volunteers.  There is also extensive documentation on-line, even for older versions of 
tomcat. See : http://tomcat.apache.org/findhelp.html


So in terms of "proof of support", what are you expecting exactly ?
I don't think that there is any other formal "proof document", other than the pages 
mentioned above.


In practical terms, examining this list and its archives (see 
http://tomcat.apache.org/lists.html) should convince anyone that the actual support of 
tomcat is pretty good, responsive and consistent over the years.


And if I am allowed a personal and subjective comment, I would add that it certainly beats 
the support available for a lot of commercial products out there.




On 21.02.2020 17:27, Hallstrom, Robert J. CTR wrote:

Good morning,


I wanted to follow up on my previous email regarding proof of support for 
earlier versions.  Please advise if anyone could ASAP.



Regards,


Robert Hallstrom
Configuration Management Specialist
Imagine One Technology & Management, Ltd.
2510 Walmer Ave. Ste. A, Norfolk, VA 23513
Phone:(757)852-6941
Cell: (757) 663-8543
Email: robert.hallst...@imagine-one.com<mailto:robert.hallst...@imagine-one.com>

From: Hallstrom, Robert J. CTR
Sent: Tuesday, January 21, 2020 10:24 AM
To: 'users@tomcat.apache.org' 
Cc: Hardemon, David (CTR) ; Powell, Tramphis W. 
(CTR) 
Subject: Apache Tomcat

Good morning,


I need documentation to prove that version 8.5.16 is still supported.  We use 
it in supporting a legacy application and need that in order to keep doing so.  
Do you know where I can find a list of what versions are still supported?




Regards,


Robert Hallstrom
Configuration Management Specialist
Imagine One Technology & Management, Ltd.
2510 Walmer Ave. Ste. A, Norfolk, VA 23513
Phone:(757)852-6941
Cell: (757) 663-8543
Email: robert.hallst...@imagine-one.com<mailto:robert.hallst...@imagine-one.com>





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

2020-02-13 Thread tomcat/perl



On 13.02.2020 11:05, logo wrote:



Am 2020-02-13 10:57, schrieb Olivier Jaquemet:

On 13/02/2020 10:32, Rémy Maucherat wrote:

On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet wrote:

On 13/02/2020 01:02, Stefan Mayr wrote:

- AJP defaults changed to listen the loopback address, require a secret
    and to be disabled in the sample server.xml

[snip]

Am I correct ? Why such a change ? Why no bugzilla issue for proper
tracking and context ?
What are your recommendations regarding AJP connector configuration ?

It is obviously best to keep default configurations as stable as possible.
But sometimes things have to change ... As a result, you'll indeed need to
adjust your server.xml according to your deployment and AJP usage.


Thank you Rémy for taking the time to answer.

I understand the need to introduce a "secured by default" AJP configuration.
However, I question one choice that was made for this change : the
default behavior of the AJP connector to listen only on the loopback
address.



+1


This is the change which is, to me, the most questionable one. Because
to my understanding, any architecture in which a remote Apache HTTPD
is being used will require a *specific IP address of the current host*
to be specified in the address attribute of the AJP connector. A
specific IP address means that the server.xml is no longer agnostic to
the platfom it is being hosted on. Prior to this, a server.xml file
could be configured in such way that it would never contain any hard
coded value related to the current host. With this change it is no
longer possible. (unless I'm missing something). For large deployment
configuration, this does seems a bit problematic.
Do you understand my concern ? Is there any way to address this ?


That's really difficult. Specifically in container environments where the container is 
started dynamically and the ip address shifts frequently. Access is done through dns or 
labels.




(The secret attribute is less of a problem, because as stated in the
documentation there is an alternative : secretRequired can be set fo
false "when the Connector is used on a trusted network".)

Make that such a breaking change in a minor maintenance update is
quite touchy. I have never seen such drastic change in my usage
history of Tomcat.



For info, there is also another thread entitled "Re: Tomcat 8.5.51 fails", which seems 
relevant to this discussion.





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



Re: Tomcat 8.5.51 fails

2020-02-13 Thread tomcat/perl

On 13.02.2020 10:36, kohm...@iris.eonet.ne.jp wrote:

On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote:

Check in the file (tomcat_dir)/conf/server.xml, the Connector :

     


The setting is the same as mine.

I have use server.xml used in 8.5.50. In case of 8.5.50, I have no problem.

Please notice, I have been using Tomcat for 5 years with updates.
Why this time?



Yes, you are right, and I am sorry for my previous short answer.
(I thought that you were a "newbie" installing tomcat 8.5 for the firdst time, and that 
you had just not configured the Connector correctly.)


But Remy's answer, and the other thread "Re: [ANN] Apache Tomcat 9.0.31 available" seems 
to indicate that this was due to a *change* in behaviour between 8.5.50 and 8.5.51.


In any case, it seems that for now, you will have to modify the AJP Connector 
configuration in server.xml, to make it work with 8.5.51 and above, and add an explicit


secretRequired="false"

attribute.  And maybe also an explicit listening address..

It looks like these changes are documented here :
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html
--> Coyote


Update:  Disable (comment out in server.xml) the AJP/1.3 connector by default. 
(markt)
Update:  Change the default bind address for the AJP/1.3 connector to be the loopback 
address. (markt)
Add:  Rename the requiredSecret attribute of the AJP/1.3 Connector to secret and add a new 
attribute secretRequired that defaults to true. When secretRequired is true the AJP/1.3 
Connector will not start unless the secret attribute is configured to a non-null, non-zero 
length String. (markt)


I think that the first change above is ok, because it only affects the distribution of 
newly-downloaded server.xml files.


But the other two also impact existing installations just being updated, and in a way that 
is not very clearly indicated in the on-line documentation. That looks a bit more iffy..



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



Re: Tomcat 8.5.51 fails

2020-02-13 Thread tomcat/perl

On 13.02.2020 10:13, kohmoto wrote:

Hi,

I have install Tomcat 8.5.51 today and found something wrong.

I have been using tomcat for last 5 years and never met this kind of problem.

It would be appreciated if I could be advised.

Thank you.

System:
CentOS 7.7.1908
httpd 2.4.41 (community version)
   httpd.conf:
     (LoadModule proxy_ajp_module lib64/httpd/modules/mod_proxy_ajp.so)
   httpd-proxy.conf:
     
   ProxyPass ajp://localhost:8009/manager/
     
tomcat 8.5.*

error log---
13-Feb-2020 17:13:12.523 重大 [main] 
org.apache.catalina.core.StandardService.startInternal Failed to start connector 
[Connector[AJP/1.3-8009]]
     org.apache.catalina.LifecycleException: プロトコルハンドラの起動に失敗しました ( 
'fail to start protocolhandler' in English )
     at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)

     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
     at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)

     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
     at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)

     at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
     at 
org.apache.catalina.startup.Catalina.start(Catalina.java:688)
     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
     at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 

     at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 


     at java.base/java.lang.reflect.Method.invoke(Method.java:567)
     at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
     at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
     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.
     at 
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
     at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)

     ... 12 more



Hi.
The log message above :

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.


seems pretty clear.

Check in the file (tomcat_dir)/conf/server.xml, the Connector :



and the associated on-line documentation :

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

search for "secretRequired".


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



Re: HTTP error response payload

2020-02-08 Thread tomcat-lists
Hi Saurav,

On 08.02.20 07:47, Saurav Sarkar wrote:
> Through tomcat access valve i can view the HTTP request url ,response code
> etc.
> 
> But i can not view the error response being sent in the form of JSON
> payload.
> 
> Is their any valve/filter/ any other setting on tomcat level which can
> enable this or applications (server and clients) themselves have to log it.

Logging HTTP request or response bodies in access logs (or similar) is not 
common as this can
be anything from a simple (short) string to long binary data. If you need 
specific errors, I
would suggest to log it in your application specific logs (you can add session 
id "%S" or other
identifiers to your access log for easier mapping, see 
https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Log_Valve
for details).

If you do not have a chance to add this to your logs you can implement a 
ServletFilter which logs
the body of requests for certain requests.

hth,
Thomas

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



Re: [OT] distinction between resource charset and format octet decoding

2020-02-06 Thread tomcat/perl

On 06.02.2020 14:44, Mark Thomas wrote:

On 06/02/2020 13:39, Garret Wilson wrote:

On 2/6/2020 10:36 AM, Mark Thomas wrote:

…

Whether Tomcat should ship with this setting present in conf/web.xml
by default is something that should probably be discussed for Tomcat
10. Given the current state of the web, there is a reasonable case for
doing so. I'll add that to the TOMCAT-NEXT discussion list.

Is this still on the list for discussion for Tomcat 10?

No, because it has already been implemented for Tomcat 10 and is in the
milestone release currently being voted on.


Waitasec. I'm not used to good news, so I want to make sure I understand
what you're saying. Are you saying that the proposed Tomcat 10
implementation already interprets encoded octets in web form submissions
using UTF-8 by default?!! :O


As of Tomcat 10, conf/web.xml contains the following:


UTF-8
UTF-8

That *should* have the effect you are looking for but I confess I
haven't tested it in any great detail.



As I am sure many people (Christopher included) would agree, the real solution would be 
for browsers and other HTTP clients to indicate clearly in the request, the 
charset/encoding of each text parameter that they are sending.

There are even HTTP headers already defined for that.
(Nowadays the default could be Unicode/UTF-8).

The problem is that browsers and other agents don't do that, although they undoubtedly 
always know themselves, and although it would solve a series of issues that have literally 
been there forever at the server and application level (*).


I have often wondered if/why the Apache Foundation does not pack enough influence over the 
HTTP/HTML specifications process and over browser producers, to achieve that.

(And if not the Apache Foundation, then who ?)


(*) My own guess is that this basic thing (or lack of it) has cost over the years many 
thousands of lines of unnecessary code and many thousands of unproductive developer hours. 
As a tiny example, just consider the above web.xml parameters, and how much time in total 
was dedicated to their definition and implementation.. Never mind all the previous related 
filters and valves and their discussions on this list. And that's only for Tomcat.


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



Re: Tomcat9, JSP, CSS and JS not loading in Firefox

2020-01-23 Thread tomcat/perl

On 22.01.2020 10:26, Lmhelp1 wrote:

Hello Chris and all,

Sorry for my late answer.
Thank you for the link you suggested me to read.
Adding the element:
UTF-8
to "web.xml" solved my problem.



Glad to hear that.
From an absolute point of view, this is of course again a "patch". But as Chris pointed 
out before, it is unfortunately an unavoidable one, due to the fact that the browsers 
lamentably fail to always indicate the character set and encoding that they are using for 
sending text data to the server.


[RANT:]
(Although they know, and although the specifications provide them with an easy way to do 
that. Why that is so is anyone's guess, but the economic losses due to that over the years 
must be staggering).

(probably close to the cost of allowing spaces in directories and files names)





On 17/01/2020 3:17 PM, Christopher Schultz wrote:

Your filter changes the encoding of both the request AND the response.
It's likely that fixing the request-encoding was necessary, while
changing the response-encoding was not.

The problem is:

1. The official RFC-defined default character encoding for HTTP is
ISO-8859-1.

2. The browser default appears to be unpredictable, but often UTF-8.

3. The browsers have all agreed not to tell the server what characted
encoding is actually being used.

It's fun. It's a very simply-solved problem: the browser should just
advertise the character encoding and everything would be great. Sadly, n
o.

I would encourage you to read this page in its entirety:
https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encoding

- -chris



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




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



Re: Tomcat9, JSP, CSS and JS not loading in Firefox

2020-01-17 Thread tomcat/perl

On 17.01.2020 04:15, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Léa,

On 1/16/20 9:33 AM, Lmhelp1 wrote:

Hello,

Thank you for your answers.

I changed /* to
*.jsp I also un-commented the line:
servletResponse.setContentType("text/html; charset=" +
Finals.S_CHARSET);

It looks like the problem is solved.

[snip]

Shall I leave *.jsp as it is, or can
you suggest another pattern?


There is a better solution:

1. Delete the files and removed references to it in web.xml

2. Edit your JSP files and properly set the content-type and encoding
in the @page directive at the top of the file.



I believe Chris had a bit too much - or too little - coffee when he wrote the above, and 
that he meant :


1. Delete the *filter* and remove all references to it in web.xml
2. ...

The point is : if your application is well-written and follows the standards, you should 
not normally need this Encoding filter, and everything should "just work".  This filter is 
probably a left-over "patch" from either an older (and incorrect) application version, or 
some older version of Tomcat.


That is why I first recommended that you remove the whole filter section from your 
web.xml, and check what happens.  Display some pages which /should/ contain some text in 
non-English languages (meaning with "diacritics" like è, é, à, ü, ö, ..) and if they 
display correctly, there is nothing else to do.


Only if you /do/ get a wrong display of some of that data, then you should come back here, 
and try to describe what is wrong. And we could then help you find the root cause.

That would be better than trying to apply a patch over a patch over a patch..


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



Re: Antwort: Tomcat9, JSP, CSS and JS not loading in Firefox

2020-01-16 Thread tomcat/perl

On 16.01.2020 10:36, Lmhelp1 wrote:

Hello,

Thank you for your answer.
Indeed, I have such a filter:

In "web.xml":

  
     EncodingFilter
com.[...].EncodingFilter
     
requestEncoding
   UTF-8
     
   
   
     EncodingFilter
     /*
   


The "doFilter()" method of the "EncodingFilter" class which implements "Filter":

     public void doFilter(ServletRequest  servletRequest,
  ServletResponse servletResponse,
  FilterChain filterChain)
     throws IOException, ServletException
     {
     // Respect the client-specified character encoding
     // (see HTTP specification section 3.4.1)
     if(servletRequest.getCharacterEncoding() == null)
     {
servletRequest.setCharacterEncoding(ms_encoding);
     }

     // Set the default response content type and encoding
     servletResponse.setContentType("text/html; charset=" + 
Finals.S_CHARSET);
servletResponse.setCharacterEncoding(Finals.S_CHARSET);

     filterChain.doFilter(servletRequest, servletResponse);
     }


Commenting the line:
servletResponse.setContentType("text/html; charset=" + Finals.S_CHARSET);
doesn't solve the problem.
I still get the error:

The stylesheet http ://localhost/fr/css/fo.css was not loaded because itsMIME type, 
“text/html”, is not “text/css”.

----



Also note :
https://tomcat.apache.org/tomcat-9.0-doc/servletapi/javax/servlet/ServletResponse.html#setCharacterEncoding-java.lang.String-

says :

"...calling this method with the String of UTF-8 is equivalent with calling setContentType 
with the String of text/html; charset=UTF-8."


So, in the above, if you have just commented-out the line :

  servletResponse.setContentType("text/html; charset=" + 
Finals.S_CHARSET);

but you left the following line unchanged

 servletResponse.setCharacterEncoding(Finals.S_CHARSET);

then executing this line is equivalent to setting the content type to 
"text/html".
And this looks suspiciously like the error you are getting..

As another way of avoiding that problem, you may also want to change in web.xml 
:

>  /*

by something that applies *only* to HTML responses.





Best regards,
--
Léa


On 15/01/2020 5:09 PM, Niall Fitzpatrick wrote:

Hi Lea,

I experienced this problem not so long ago when we upgraded our Tomcat to a later 
version of 9. Basically we had a filter applied to requests which was supposed to set 
the encoding of the response to be UTF-8. However, it was also setting the content type 
to text/html.


Previous to the Tomcat upgrade it wasn't an issue. I found that in one of the Tomcat 
updates (can't remember which one) the logic of the default servlet was altered such 
that if the content type has already been set in the response it can't be set again 
further down stream. So my resolution was to remove the line that set the content type 
in our filter.


Something to check anyway as it took me some time to figure out what was 
happening.

Niall



-
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: Antwort: Tomcat9, JSP, CSS and JS not loading in Firefox

2020-01-16 Thread tomcat/perl

On 16.01.2020 10:36, Lmhelp1 wrote:

Hello,

Thank you for your answer.
Indeed, I have such a filter:

In "web.xml":







[...]

What happens if you disable that filter entirely, in web.xml ?
(comment-out the whole section above, as shown)

Note : ignore any character encoding errors that you may get in the response, 
for now.
(probably shown as ).  The point is to verify if it is really that filter which causes 
the problem with the CSS files.


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



Re: Expected behavior of calling javax.servlet.ServletRequest#getInputStream after javax.servlet.http.HttpServletRequest#getPart

2019-12-10 Thread tomcat/perl

On 10.12.2019 15:31, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Behrang,

On 12/8/19 05:18, Behrang Saeedzadeh wrote:

If I call javax.servlet.ServletRequest#getInputStream after having
called javax.servlet.http.HttpServletRequest#getPart, even without
performing any operations on the given part, I am getting an empty
stream (0-bytes).

Is this in compliance with the spec?


What does the servlet spec say about that situation?



A bit in defense of the OP, I have to say that the Servlet Spec (4.0 final) does not seem 
extremely clear on that subject.

In section "3.1.1 When Parameters Are Available", it /does/ say this :

"If the conditions are met, post form data will no longer be available for
reading directly from the request object’s input stream."

But among those conditions that have to be met (just above that quote) is
"4. The servlet has made an initial call of any of the "getParameter family" of 
methods
on the request object."

(So there, it talks about "the getParameter family", not the "getPart" ones).

It only talks about the "getPart" methods in the next section "3.2 File upload", and in 
that section, all it says about the input stream is :

"If the servlet container does not provide the multi-part/form-data processing,
the data will be available through the HttpServletReuqest.getInputStream."

So the way I read this, is that there is nothing that explicitly says that the InputStream 
is no longer available if you have called "getPart".


(It is also in fact not very clear about what happens to the parameters, when the 
content-type of the Request is "multipart/form-data", which is only mentioned in section 3.2.)


On the other hand,
http://tomcat.apache.org/tomcat-9.0-doc/servletapi/index.html
--> Interface HttpServletRequest
says :

Part getPart(java.lang.String name)
  throws java.io.IOException,
 ServletException
Gets the named Part or null if the Part does not exist. *Triggers upload of all 
Parts*.
(emphasis mine)

which /may/ be taken to mean (and probably does) that it consumes the whole 
InputStream.

But again, this may be lacking some overall clarity.

In any case, the OP's question is not really unwarranted, unless there is some other 
explanation somewhere which I have missed.





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



Re: Bouncing Tomcat from HTTPD?

2019-12-09 Thread tomcat/perl

On 05.12.2019 19:56, Jerry Malcolm wrote:

I was stuck in traffic an hour from the office when I got a text that one of my 
sites had
gone down.  If I'd been in the office, I'd try bouncing TC first just to try to 
get the
client back online, then dig into the logs to figure out what happened.  But 
while driving
on the freeway, there's no way to access ssh into the server and key in the 
command to
restart tomcat.  httpd was working fine.  It would have been nice to bring up a 
non-tomcat
web page on my phone and press a button to cause the tomcat service to restart. 
 I know I
could probably write something in php or perl or something.  But I don't want 
to reinvent
the wheel.  Are there some packages available that already do something like 
this?



Sorry, but since using one's mobile phone while driving is known as dangerous and even 
against the law in many places, the security-conscious and law-abiding Tomcat support team 
does not think it can answer the question as phrased above.


Now if you were to rephrase it, leaving off the "while driving" bit, we might tell you 
that some such things probably exist already, but that you would have to look at 
admin-like utilities or packages belonging to your OS distribution, as there is nothing in 
Tomcat itself which provides such a capability.(*)
We may also then warn you about the security aspect of such things, because one would 
probably not want to allow the general public to restart one's Tomcat server through an 
open webpage.


(*) (If there was such a capability, there would also be the interesting philosophical 
question of how to use it, if the Tomcat server is down).




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



Re: Double Slash Support in Tomcat 9.0.27

2019-12-09 Thread tomcat/perl

Hi Christopher.

I believe that yours is a really good explanation of why Tomcat collapses consecutive 
slashes in URLs.

It's certainly worth a FAQ article, in case the question ever pops up again.

It maybe even be worth a note somewhere in the main documentation, such as where it 
explains how Tomcat actually maps URLs to webapps. Except that I can't locate the 
documentation which specifically explains this..

Maybe this is because Tomcat normally refers to the Servlet Spec for this ?

The closest I find is here : 
http://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Naming
Maybe inserting a note to the effect of 'Note: before any of the mapping below takes 
place, Tomcat collapses any consecutive "/" characters in the path portion of the URL to a 
single "/". The complete explanation is here : --> FAQ article" '



On 05.12.2019 17:13, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 12/5/19 04:55, André Warnier (tomcat/perl) wrote:

Christopher,

I believe that the problem of the OP is that either this filter or
the application, *relies* on the fact that Tomcat would NOT
collapse multiple consecutive slashes in the URL, to a single
slash. That (the non-collapsing) seems to have been the case in
some previous versions of Tomcat, and has apparently been changed
in more recent versions of Tomcat (and probably rightly so, to
adhere more strictly to the specs).


Actually, it's somewhat in *violation* of the specs. But it's a
generally-accepted violation because it allows security rules to
actually remain sane.

If you want to protect "/foo/bar.html" which maps to a file on the
disk, you'll find that the filesystem collapses slashes and will load
that same file regardless of how many extra slashes you put in there.
"/foobar.html" is going to give you the same result.

The same is true for multiple levels like "/foo/bar/bar.html". If you
want to protect all files in "/foo/bar" it's not practical to add
protections for "/foo/bar/" and "/foo//bar/" and "/foo///bar/" and ...
you see where I'm going with this.

So the server decides that slash-collapsing will allow security
constraints to be more practically applied.

What if we get super-spec-compliant and allow those extra slashes?
Well, you'd have to get really (and, IMHO, /overly/) strict about how
those slashes are treated. In Java, you'd have to do something like this
:

String path = ... // file-path from request
String docRoot = ... // docroot base, absolute
File file = new File(docRoot, path);
if(!file.exists())
  // return 404
if(!path.equals(file.getAbsolutePath().substring(docRoot.length()))
  // return 404

That last check will check to make sure that the path requested by the
client *exactly equals* that of the path on the disk. That means that
multiple-slashes are essentially forbidden when requesting disk-files.

(It gets more fun when you are requesting a directory which has an
"index file" like index.html and you have to decide whether or not
it's okay to load that file automatically, even though the client
didn't specifically request it.)

So now we are spec-compliant. Yay! Except that all those sloppy
webmasters links no longer work because they do all kinds of weird URL
manipulations that don't always result in a perfectly-clean URL. So
we've achieved spec-compliance and inconvenienced users. Did we really
achieve anything? Those multi-slash URLs were never going to work. It
is really a big deal to just ... let them work? So we collapse slashes
and everything is fine. Nobody is really going to complain if
/foo//bar.html and /foo/bar.html both work instead of one of them
returning 404.

What about resource that are *not* on a disk? Like servlets and stuff
like that? Well, the servlet spec allows us to map to URL patterns of
various types. Some are exact, others prefixes, etc. We can also
define security constraints with the same kind of url-pattern basis.
Generally, those things should agree. What happens when you introduce
multiple-slashes in there?

Well, nobody is ever going to map a bunch of additional slashes to
make their servlets work properly. So we are back to the same problem
as the on-disk-file: the multiple-slashes are essentially forbidden if
we want to be super-spec-compliant. So we relax a little and take the
practical approach: collapse slashes and move on with our lives. This
has the added benefit of making security constraints more consistent,
and fewer mistakes. And encouraging fewer security mistakes is a Good
Thing.


And the collapsing of multiple consecutive slashes in the URL, is
probably done at such an early stage in the request processing,
that it is not easy to do something to turn it off (which may or
may not be spec-compliant anyway).


Turning it off would be a giant mess. And yes, it needs to be doe
quite early because Tomca

Re: Double Slash Support in Tomcat 9.0.27

2019-12-05 Thread tomcat/perl

Christopher,

I believe that the problem of the OP is that either this filter or the application, 
*relies* on the fact that Tomcat would NOT collapse multiple consecutive slashes in the 
URL, to a single slash.
That (the non-collapsing) seems to have been the case in some previous versions of Tomcat, 
and has apparently been changed in more recent versions of Tomcat (and probably rightly 
so, to adhere more strictly to the specs).
And the collapsing of multiple consecutive slashes in the URL, is probably done at such an 
early stage in the request processing, that it is not easy to do something to turn it off 
(which may or may not be spec-compliant anyway).


I did not look up the HTTP specs to find where this collapsing of slashes is specified, 
but I found this in the Apache httpd documentation, which would seem to suggest that 
consecutive slashes are not necessarily invalid, and may even *mean* something :

http://httpd.apache.org/docs/2.4/mod/core.html#location
(see : Note about "/")

Ok, then I got curious and did have a quick look at RFCs 7230 and 7231, and they are mute 
about consecutive slashes.  RFC2396 on the other hand does not seem to forbid consecutive 
slashes, and as I understand it, they are even "significant", as they seem to delimit a 
path element (which just happens to be empty).
https://tools.ietf.org/html/rfc3986#section-3.3 does not seem to forbid consecutive 
slashes either.


But I would suppose that if the Tomcat developers decided to collapse multiple consecutive 
slashes, they must have had a reason.


On 04.12.2019 15:18, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kushagra,

On 12/4/19 06:32, Kushagra Bindal wrote:

I am not saying that this is a tomcat issue, I am just asking if
there is a way by which we can handle this. As maybe in later
version of 8.5.24 Tomcat has take some action to handle such
conditions.


I still don't really see the problem. Your responses have included
tiny bits of information separately and not everything all at once. If
you have a  defined and mapped to a URL pattern, it should
work and not give you a 404.

Try this with the examples application:

http://localhost:8080/examples/servlets/servlet/HelloWorldExample

It will respond no matter how any slashes you put in various places:

http://localhost:8080/examples/servlets/servlet//HelloWorldExample
http://localhost:8080/examples/servlets//servlet//HelloWorldExample
http://localhost:8080/examples/servlets/servlet//HelloWorldExample

There are no 404 errors.

Are you sure your application has deployed correctly?

- -chris


On Wed, Dec 4, 2019 at 4:53 PM Mark Thomas 
wrote:


On 04/12/2019 05:16, Kushagra Bindal wrote:

Hi Mark/Manna/Chris,

Do we have any way out to handle this type of behavior?


All the evidence so far points to an application issue, not a
Tomcat issue.

If you are able to create a simple test case that demonstrates a
Tomcat issue we can take a look.

Mark




On Tue, Dec 3, 2019 at 5:46 AM Kushagra Bindal <

bindal.kusha...@gmail.com>

wrote:


Chris,

If you will check in my early email then you will find that
with // it

is

throwing 404. But as soon as I removed it manually then it
starts

working

properly and all these url were working fine in 8.5.24
version.

On Tue, Dec 3, 2019, 1:21 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Kushagra,

On 12/2/19 11:29, Kushagra Bindal wrote:

I think it should be.


DanglingSessionInvalidateFilter



DanglingSessionInvalidateFilter

com.SessionInvalidateFilter
 
DanglingSessionInvalidateFilter



/restcall/* 


Here in below URL:

"http://backend_tomcat:8080/sdm/restcall/v1/platform//healthChec

k"





sdm will be the context path.


But in another example that I shared in my last email,
one use case
http://backend_tomcat:8080//sdm/restcall)(.*)/file_uploads
my context path itself contains //.

So, please suggest a viable solution which we can try
to solve this problem. :)

Thanks in advance for your help & support in resolving
this issue.


All of these slashes really should be collapsed into a single
slash before processing. I don't see an issue. If the client
requests:

http://backend_tomcat:8080/sdm/restcall/v1/platform//healthCheck




then the filter/servlet at /sdm/restcall/* will respond.


If the client requests:

http://backend_tomcat:8080//sdm/restcall/foo/file_uploads

Then the filter/servlet at /sdm/restcall/* will respond.

It doesn't really matter how many extra slashes the client
adds... they should all be collapsed by the server and your
application should not have to make arrangements to handle
them, add them back, or worry about whether they are there or
not.

-chris


On Mon, Dec 2, 2019 at 9:00 PM Mark Thomas
 wrote:


On 02/12/2019 10:59, Kushagra Bindal wrote:

Hi Mark,

These are Rest Endpoints, and so will be processed
through Filter.


That is unusual.


Do, you think Servlet mapping will play a

[OT] Re: FW: tomcat creating new ssl session id for same session

2019-11-29 Thread tomcat/perl

On 29.11.2019 06:59, rekha...@dell.com wrote:

Highly Restricted - Confidential

...

Then maybe a public list, which is also archived for years in various places, is not the 
best communication channel ?



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



Re: tomcat service app

2019-10-31 Thread tomcat

On 30.10.2019 22:03, Mark Thomas wrote:

On October 30, 2019 7:41:07 PM UTC, George Stanchev 
 wrote:

My question about the source stays, but I guess I should've RTFM where
it states that the wrapper uses # *or* ; as separator and if you want
to embed those character you need to wrap them in single quotes...

From: George Stanchev
Sent: Wednesday, October 30, 2019 1:33 PM
To: Tomcat Users List 
Subject: tomcat service app

I am trying to troubleshoot an issue where when I call tomcat8.exe with
following parameters it writes [2] to the registry (newline where the
semicolon was) and I am having trouble locating the source code
repository for the Windows service app. Can someone point me to it? (Or
tell me what I've done wrong with that property value)

George


[1] tomcat.exe //US//SbmTomcat --Jvm "C:\Program
Files\myapp\jre1.8\bin\server\jvm.dll" --JvmOptions
"...#-Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext;C:\Program
Files\myapp\jre1.8\lib\ext.fips#..."
[2]
...
-D Djava.ext.dirs=C:\Program Files\myapp\jre1.8\lib\ext
C:\Program Files\myapp\jre1.8\lib\ext.fips


It is Apache Commons Daemon. Source here:
https://github.com/apache/commons-daemon

Mark



And maybe this helps, as a general explanation :
https://cwiki.apache.org/confluence/display/TOMCAT/Windows#Windows-Q11




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



Re: Cannot add dependency job for unit systemd-console-setup.service

2019-10-20 Thread tomcat

On 20.10.2019 10:07, Emefile Francis Nwajie wrote:

Hello All,

Top of the day to you.

I have a VPS with CentOs 7.
I am trying to start-up Tomcat 9.0.27 using "systemctl start tomcat". And I
got the error message - "Cannot add dependency job for unit
systemd-console-setup.service".

I am wondering if there is something I have to setup in my CentOS 7 VPS or
if it is an issue with Apache Tomcat 9.



Searching Google for "Cannot add dependency job for unit systemd-console-setup.service" 
gives plenty of results (including you own message to this list), most of which seem to 
refer to some systemd issue in various Linux distributions.

So, on the face of it, it does not look like a tomcat issue.
Maybe an issue of the particular packaged distribution of tomcat that you are using with 
CentOS 7 ?





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



Re: tomcat 8 post call lost in process

2019-10-18 Thread tomcat

Hi.

It is unfortunately a bit difficult to make sense of the description and information that 
you provide below.


But one thing is quite certain :
By the time tomcat (if I understand correctly, the one that you call the "slave") writes a 
line to its access log, with a result code "200 OK", it means that this tomcat not only 
*received* the request, but also that it *processed* this request, succesfully, *and* sent 
the response back (also succesfully) to whoever sent this request to it.


It is difficult to read the tcpdump log that you provide below, but it looks like it also 
shows that for each POST from the "master" to the "slave", there is a HTTP response with 
code 200 OK, from the "slave" to the "master".

Why do you think that these responses are being "lost" ?

Maybe you should have a closer look at the application on the "master" side, to see why it 
does not seem to catch the slave responses ?


Also, take into account that if the /application/ on the "master" side makes a connection 
to the slave, this is not tomcat code, it is the application code, and tomcat itself (the 
master) knows nothing about this. So there is little that we can do to help you.




On 18.10.2019 15:57, Saurabh Barthwal wrote:

Hi Team,
I am facing one unusual problem with tomcat. I am using 2 tomcat server for
master and slave architecture.
when master send's HTTP request(POST) to slave if slave is taking more then
1 hr then the slave tomcat is not responding back but in slave tomcat's
localhost_access.log is showing request as 200 ok but that is not revived
by master tomcat server there is no time out (we are using infinite
connection time out ) send I checked master's tcp connection after 1 hr it
is good(ESTABLISHED).

So I tried to capture all requests at slave server's tcp port by tcpdump
but the request is lost after tomcat logs into   localhost_access.log(as a
success) but not went to tcp port. No idea where the request lost.

Details and logs :
tomcat 8.0

*localhost_access_log.txt of slave*

xx.xx.xx.xx - - [18/Oct/2019:08:51:07 -0400] "POST /path/process5 HTTP/1.1"
200 2737


*tcpdump output at slave *

reading from file /tmp/http18103.log, link-type EN10MB (Ethernet)
07:36:32.960401 IP xx.xx.xx.xx.52978 > slaveServer.webcache: Flags [P.],
seq 282516513:282516889, ack 3687166207, win 229, options [nop,nop,TS val
3093985757 ecr 3091920822], length 376: HTTP: POST /path/process1 HTTP/1.1
07:36:34.783281 IP slaveServer.webcache > xx.xx.xx.xx.52978: Flags [.], seq
1:2577, ack 2838, win 280, options [nop,nop,TS val 3091922673 ecr
3093985759], length 2576: HTTP: HTTP/1.1 200
07:36:45.022982 IP xx.xx.xx.xx.53120 > slaveServer.webcache: Flags [P.],
seq 1539707126:1539707502, ack 2187000281, win 229, options [nop,nop,TS val
3093997820 ecr 3091932884], length 376: HTTP: POST /path/process2 HTTP/1.1
07:36:56.300518 IP slaveServer.webcache > xx.xx.xx.xx.53120: Flags [.], seq
1:2577, ack 3329, win 300, options [nop,nop,TS val 3091944190 ecr
3093997820], length 2576: HTTP: HTTP/1.1 200
07:36:56.512553 IP xx.xx.xx.xx.53232 > slaveServer.webcache: Flags [P.],
seq 2909077325:2909077700, ack 2040056900, win 229, options [nop,nop,TS val
3094009310 ecr 3091944374], length 375: HTTP: POST /path/process3 HTTP/1.1
07:37:27.209286 IP slaveServer.webcache > xx.xx.xx.xx.53232: Flags [.], seq
1:2577, ack 3557, win 300, options [nop,nop,TS val 3091975099 ecr
3094009310], length 2576: HTTP: HTTP/1.1 200
07:37:27.404865 IP xx.xx.xx.xx.53551 > slaveServer.webcache: Flags [P.],
seq 1996723440:1996723817, ack 1343133109, win 229, options [nop,nop,TS val
3094040204 ecr 3091975267], length 377: HTTP: POST /path/process4 HTTP/1.1
07:37:28.932928 IP slaveServer.webcache > xx.xx.xx.xx.53551: Flags [.], seq
1:2577, ack 3548, win 300, options [nop,nop,TS val 3091976823 ecr
3094040204], length 2576: HTTP: HTTP/1.1 200
07:37:29.120056 IP xx.xx.xx.xx.53580 > slaveServer.webcache: Flags [P.],
seq 1734970332:1734970711, ack 390079555, win 229, options [nop,nop,TS val









*3094041920 ecr 3091976982], length 379: HTTP: POST /path/process5
HTTP/1.108:51:23.325430 IP slaveServer.webcache > xx.xx.xx.xx.53580: Flags
[.], seq 1:2577, ack 5366, win 326, options [nop,nop,TS val 3096411215 ecr
3094041920], length 2576: HTTP: HTTP/1.1 20008:51:23.607888 IP
slaveServer.webcache > xx.xx.xx.xx.53580: Flags [.], seq 1:1289, ack 5366,
win 326, options [nop,nop,TS val 3096411498 ecr 3094041920], length 1288:
HTTP: HTTP/1.1 20008:51:24.066861 IP slaveServer.webcache >
xx.xx.xx.xx.53580: Flags [.], seq 1:1289, ack 5366, win 326, options
[nop,nop,TS val 3096411957 ecr 3094041920], length 1288: HTTP: HTTP/1.1
20008:51:24.985860 IP slaveServer.webcache > xx.xx.xx.xx.53580: Flags [.],
seq 1:1289, ack 5366, win 326, options [nop,nop,TS val 3096412876 ecr
3094041920], length 1288: HTTP: HTTP/1.1 20008:51:26.821888 IP
sla

[OT] Re: Question about DirResourceSet?

2019-10-14 Thread tomcat

From a long-time (occasional) list contributor :
That's a nice post, in many ways, and a good way to get quick and useful 
answers.
I only regret that my own knowledge is not sufficient to provide such an answer.
(We regularly complain at people posting to this list, when their post is "not nice", so I 
thought we should also from time to time give kudos when it is).


On 14.10.2019 16:37, Robert Olofsson wrote:

Hi!

Some background:
We are currently running tomcat (9.0.26) and we serve data to
both html/webapp and to our java application. The java application
uses a lot of the same jar files that our servlets use.

We have had tomcat setup with two directories:
1) webapps//WEB-INF/lib (as usual for servlet classes)
2) webapps//clientdir/ (jar files for the java application).

This means that we have a lot of duplication of jar files in these two
directories.

We would like to have the duplicate files in only one place, sure
disk space is cheap, but data transfer takes time. We thought that
having the jars in the clientdir would be nice.

We have read the documentation for tomcat and found the resource handling
and it looks like we could possibly use something like:


   


We tested this lightly and things seems to work.

Questions:
Is there any problem with this?
If so, do you know of any better way to accomplish this?

Thanks
/robo


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




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



Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

2019-10-13 Thread tomcat

Hi.

On 12.10.2019 02:17, George S. wrote:

I'm a little confused. What would one hope to gain by doing this?


I'm not that much of an expert on Tomcat or its "ecological niche", but in a general 
overall point of view, I would tend to say that anything that "opens up" tomcat to more 
programmers and more users cannot really be a bad thing.
As an example, maybe off-track : there are a lot of web applications based on ruby, 
python, javascript, perl, php, etc.. Mostly, they are based on development frameworks 
similar to the ones for JSP pages, only written in something else than java.  Porting 
these to tomcat using the CGI model is not really practical, and translating them to Java 
and JSP isn't either. (Apart from the fact that in order to really dominate java, you 
pretty much have to spend all your time on it.)
So if this "javax.script" would provide a shortcut to run, with minimal adaptations, pages 
written using some of these other languages, if only temporarily and as a prototype, why not ?


Of course there is a cost, and as Christopher previously pointed out, some previous 
attempt at this did not seem to have had many takers, and it pretty much seems to have 
died by lack of interest.
But then again, in terms of market coverage as a webserver, the cost for tomcat to be 
"single language centric", is certainly not null either.




On 10/8/2019 9:11 AM, Rony G. Flatscher (Apache) wrote:

Does anyone know of any tutorials that would demonstrate how to use any 
javax.script
language in
JSPs instead of Java (e.g. using Jython or JavaScript instead)?

If not, any advice/hint how to realize/create such a functionality (for then 
creating
such a
tutorial instead) would be highly appreciated!

---rony




-
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 with SiteMinder

2019-10-11 Thread tomcat

On 11.10.2019 05:11, Bauer, Margaret M (Peggy) wrote:

Has anyone used tomcat with SiteMinder without having a webserver in front
of it?  If so, where can I find the how to?


In the SiteMinder documentation ?
(No kidding. As I recall, they do provide examples with multiple webservers.)



thank you,

*Peggy *




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



Re: Any tutorials or hints about JSP using javax.script engines instead of Java?

2019-10-08 Thread tomcat

On 08.10.2019 17:11, Rony G. Flatscher (Apache) wrote:

Does anyone know of any tutorials that would demonstrate how to use any 
javax.script language in
JSPs instead of Java (e.g. using Jython or JavaScript instead)?

If not, any advice/hint how to realize/create such a functionality (for then 
creating such a
tutorial instead) would be highly appreciated!



I know nothing about the subject matter, but was searching Google for "javax.script 
language jsp" and found this :

http://wi.wu.ac.at:8002/rgf/diplomarbeiten/BakkStuff/2010/201007_Ryabenkiy/201007_Ryabenkiy_WebScripting_ApacheTomCat_TagLib.pdf
(look around page 50).
Does this help ?

On the side, even though (or maybe because) I did not previously know anything about this, 
I found this document really impressive in terms of providing a terse but extremely 
readable background of the whole thing, all the way to some practical examples, all in 
less than 100 pages. And this was a bachelor's thesis. So I don't know if it helps you, 
but I enjoyed it.
Looking up the author in Google, it doesn't seem that he really needs my modest plaudits 
though.




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



Re: Acessing static content - Tomcat 7 vs. Tomcat9

2019-10-08 Thread tomcat

On 08.10.2019 13:41, Martin Knoblauch wrote:

Hi Andre,

thanks for the extensive response. this is really appreciated. See below
for comments

On Mon, Oct 7, 2019 at 10:27 PM André Warnier (tomcat) 
wrote:


Hi.
see at end.



Then the browser tells me that "The page isn’t redirecting properly".

What one can see above is that the POST is now redirected, but the

trailing

"/" is not added as I would have expected using the two mapper directives
...

Not only that, but also all the subsequent browser GET requests for
"/cb2/docs", get a 302
response with a HTTP header :
Location: /cb2/docs
So the browser immediately re-issues a request for "/cb2/docs", which
receives the same
response, etc.
Until the (smart) browser realises that it is always requesting and
receiving the same
thing and calls quits.





What you are showing above as log, is only the httpd access log.
Do you have an access log enabled in tomcat, and do you see these same
accesses there ?
(And if yes, then forget all the rest below).



Yes, we have access logging enabled for Tomcat and for the TC9 setup I *DO
NOT* see requests for "/cb2/docs" in there.

Looking at the TC7 setup I can find the access and redirect in the Tomcat
access log:

160.46.219.110 - - [08/Oct/2019:12:49:31 +0200] "POST /cb2/docs HTTP/1.1"
302 -



Aha.  So it looks like, with Tomcat 9 in the back-end, these requests are not even being 
proxied to Tomcat, and that it is httpd in that case which returns the 302's.

Why that would be, with everything else being identical, is also a puzzle to me.
But it's still better that looking uselessly in some Tomcat configuration issue.

Maybe this will give someone else on the list an idea ..

In the meantime, a question : considering your JkMount/JkUnmount directives below, you do 
have some files locally under Apache httpd's filesystem, which you want to serve directly 
from httpd.
Would you have any other configuration sections with  which cover these 
files, and /may/ be interfering/overriding the JkMount/unmount logic ?
(Agreed, this is a long shot, and whatever they are, they should do the same whether it is 
t7 or t9 in the back-end, but again, one never knows..)





Or else, can you modify the "LogLevel" directive in httpd, so that you see

(in the httpd
error log) how (or if) these accesses are really being proxied to tomcat ?
(à la "Loglevel info proxy:debug proxy_ajp:debug" e.g.)



Have added "JkLogLevel debug" to the mod_jk setup. Nothing interesting to
see there. So I am still confused here.

Based on this, from a previous post :

quote
#
# CB2 - Portal
#
# Mount the "/cb2" application to worker "cb2"
#
   JkMount /cb2/* cb2
#
# Unmount "/cb2/docs" from worker "cb2" to allow static content
# beeing served by apache. Same for "/cb2/cgi-bin"
#
   JkUnMount /cb2/docs/* cb2

So we JkUnMount the "/cb2/docs" directory from the application base in
order to server the content directly from Apache. "docs" itself is a
symbolic link pointing outside the application base.

unquote

, I would indeed tend to say that a request with the URL "/cb2/docs"
SHOULD be proxied to
tomcat (and that the redirect should thus be coming from tomcat), but
better make
absolutely sure maybe ? (hence the additional logging above)

The thing I'm unsure of myself, is this :
Apache httpd gets the original request first. Initially, it doesn't know
if this request
should be proxied to tomcat or not. So, in its "map to storage" phase -
which happens
fairly early in the request processing -, it might try to map this URL to
its local
filesystem. Because you do indeed have files locally under /cb2/docs/, it
would then find
that "/cb2/docs" is indeed a directory (or a link to ditto).
Now two things can happen, depending on the stage at which the mod_jk
proxying directives
intervene in httpd :
- either httpd considers that the request, being for a directory, should
have a trailing
"/", and *httpd* issues the 302 redirect to the browser, without even
getting to the
proxying-to-tomcat stage
- or the proxying directive has insinuated itself somewhere in-between,
and httpd does in
fact proxy the original request to tomcat (rather than trying to map it to
its own
filesystem first), and it is tomcat (which also would need to find a
directory at
../webapps/cb2/docs) which issues that redirect.

I do not know which of the above is true, because I am unsure of the httpd
request cycle
stage at which mod_jk inserts its URL mapping logic.
But the logs which you have so far provided do not really *prove* that
these requests make
it to tomcat. So, if it was me, before spending time maybe looking in the
wrong place, I
would want to make sure of that first.

Another way would be to enable some local debugging console in the
browser, and have a
look at what thes

Re: user and certificate info is not passed to tomcat

2019-10-07 Thread tomcat

On 08.10.2019 00:50, Magosányi Árpád wrote:

On 10/7/19 11:29 PM, André Warnier (tomcat) wrote:


 DirectoryIndex off
 RewriteEngine Off
 AuthType openid-connect
 AllowOverride None
 AuthzDBDQuery "a correct database query"
 Require dbd-group allrepo
 LogLevel debug



Nice. It have solved the problem, thank you very much. By adding the ssl
related directives here I could pass the ssl info as well. So basically
we have put the JkMount in a Location, and the other directives in
another similar directive, as a kind of workaround?


Think of it as follows :
When httpd gets a request,
- step 1 : it first looks only at the request URL, and it applies any directives that it 
finds in  or  sections which match that URL.
- step 2 : then it tries to match the URL, with the filesystem on disk, and IF it finds a 
file that corresponds to that URL

- step 3 : then it applies any  or  that apply 
to that file
- step 4 : httpd serves the file back to the browser

If you have JkMount directives that match the URL, then step 2, 3 and 4 above never 
happen, because the request will be passed to tomcat anyway, so it will never map to a 
file on the httpd filesystem. And if you have JkUnmount directives, that also match the 
URL, then they partially negate the matching JkMount, and they /force/ step 2, 3 and 4.


The combination of JkMount/JkUnmount directives, with the httpd  and 
 sections, is sometimes a bit unclear, specially when they overlap.


There is another syntax applicable to the proxying via mod_jk, which I prefer because I 
find that it makes the httpd URL mapping clearer, in a httpd configuration logic sense.

You can find it here :
http://tomcat.apache.org/connectors-doc/reference/apache.html
section : Using SetHandler and Environment Variables

Using that form, you do NOT use any "JkMount/JkUnmount" directives, you use only 
 blocks, like :



  SetHandler jakarta-servlet
  SetEnv JK_WORKER_NAME worker1
  DirectoryIndex off
  RewriteEngine Off
  AuthType openid-connect
  AllowOverride None
  AuthzDBDQuery "a correct database query"
  Require dbd-group allrepo
  LogLevel debug


The combination of the , SetHandler and SetEnv, does the same as 
a separate "JkMount /servlet* worker1" and (in my view) it makes it clearer in the Apache 
httpd configuration file, to know which URLs get proxied to tomcat and which do not get 
proxied.
Look at the example "" to see how you can have some static documents 
served by the httpd front-end directly (= not proxied to tomcat), and the real calls to 
tomcat servlets being proxied to tomcat.








-
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: user and certificate info is not passed to tomcat

2019-10-07 Thread tomcat

Adding to my own previous post :

A posteriori, I saw a question here :
https://stackoverflow.com/questions/58240796/pass-username-and-client-certificate-from-apache-to-tomcat-using-mod-jk
that may be related to your question on this list.
Examining the above, you problem may be in the httpd configuration :
As I interpret it, the  section that you mention, will not be taken into 
account for the URLs that you are proxying to tomcat.
That is because  sections only apply if the URL ultimately maps to a local file 
for httpd. In this case, it does not, because you are proxying this request to tomcat. For 
such URLs, you should use a  or  in httpd, not a .

For example, *add* this to your httpd configuration :

DirectoryIndex off
RewriteEngine Off
AuthType openid-connect
AllowOverride None
AuthzDBDQuery "a correct database query"
Require dbd-group allrepo
LogLevel debug


Note: the above is very rough, and you may need to tune the regex a bit better.

On 08.10.2019 00:11, André Warnier (tomcat) wrote:

On 07.10.2019 23:24, Magosányi Árpád wrote:

On 10/7/19 8:20 PM, André Warnier (tomcat) wrote:


Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?



Yes, I did, however adding it back did not improve the situation.


Ok. I just mentioned that, because it is one piece of the puzzle, and you might 
have
forgotten it.
What this piece really does is :
- IF the front-end Apache httpd authenticates the HTTP request which it later 
passes on to
tomcat
- IF the protocol used between Apache httpd and tomcat is AJP
- IF the AJP Connector in tomcat has the attribute set as above
- THEN tomcat will retrieve the user-id of the httpd-authenticated user, and 
save it
internally as the tomcat-authenticated user-id for this request

So now you have the two last IF's answered positively.
What about the first IF ?

Info : in the default format of the Apache httpd access log, it will show the
authenticated user (if any) for each request, for example like this :

127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET 
/starwebtt-internal/esearch...
(where "THEUSER" is the httpd-authenticated user)

while if the request is not authenticated by httpd, it will show a "-" instead 
of the
user-id, like this :
127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch...

(and, of course, if httpd has not authenticated the request which it later 
passes on to
tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot 
retrieve
this user-id, and thus the request, at the tomcat level, is not authenticated).


Next comes the question of how the tomcat application retrieves this user-id, 
from tomcat
itself. I suppose that this would be a question for the developers of the
"com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your 
configuration below.
(if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses 
some other
method, then you are out of luck for this front-end/back-end combination)(or 
you may need
to do something additional at the front-end httpd level).




My server.xml now:



   
   
   
   
   

   
 
   

   

 


 

   
 
   

   

 

   
 
   


and my web.xml until mime mappings:

http://xmlns.jcp.org/xml/ns/javaee;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
   http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd;
   version="4.0">


 
 default

org.apache.catalina.servlets.DefaultServlet
 
 debug
 0
 
 
 listings
 false
 
 1
 


 
 jsp
 org.apache.jasper.servlet.JspServlet
 
 fork
 false
 
 
 xpoweredBy
 false
 
 3
 


 
 default
 /
 

 
 jsp
 *.jsp
 *.jspx
 

   
 KKAuthorizationFilter

com.kodekonveyor.realm.KKAuthorizationFilter
   

   
 KKAuthorizationFilter
 /*
 REQUEST
   

 
 30
 










-
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: user and certificate info is not passed to tomcat

2019-10-07 Thread tomcat

On 07.10.2019 23:24, Magosányi Árpád wrote:

On 10/7/19 8:20 PM, André Warnier (tomcat) wrote:


Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?



Yes, I did, however adding it back did not improve the situation.


Ok. I just mentioned that, because it is one piece of the puzzle, and you might have 
forgotten it.

What this piece really does is :
- IF the front-end Apache httpd authenticates the HTTP request which it later passes on to 
tomcat

- IF the protocol used between Apache httpd and tomcat is AJP
- IF the AJP Connector in tomcat has the attribute set as above
- THEN tomcat will retrieve the user-id of the httpd-authenticated user, and save it 
internally as the tomcat-authenticated user-id for this request


So now you have the two last IF's answered positively.
What about the first IF ?

Info : in the default format of the Apache httpd access log, it will show the 
authenticated user (if any) for each request, for example like this :


127.0.0.1 - THEUSER [07/Oct/2019:21:18:20 +0200] "GET 
/starwebtt-internal/esearch...
(where "THEUSER" is the httpd-authenticated user)

while if the request is not authenticated by httpd, it will show a "-" instead of the 
user-id, like this :

127.0.0.1 - - [07/Oct/2019:21:18:20 +0200] "GET /starwebtt-internal/esearch...

(and, of course, if httpd has not authenticated the request which it later passes on to 
tomcat via AJP, then it cannot pass a user-id to tomcat, and thus tomcat cannot retrieve 
this user-id, and thus the request, at the tomcat level, is not authenticated).



Next comes the question of how the tomcat application retrieves this user-id, from tomcat 
itself. I suppose that this would be a question for the developers of the 
"com.kodekonveyor.realm.KKAuthorizationFilter" filter mentioned in your configuration below.
(if the KKAuthorizationFilter does not use request.getRemoteuser(), but uses some other 
method, then you are out of luck for this front-end/back-end combination)(or you may need 
to do something additional at the front-end httpd level).





My server.xml now:



   
   
   
   
   

   
 
   

   

 


 

   
 
   

   

 

   
 
   


and my web.xml until mime mappings:

http://xmlns.jcp.org/xml/ns/javaee;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
   http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd;
   version="4.0">


 
 default

org.apache.catalina.servlets.DefaultServlet
 
 debug
 0
 
 
 listings
 false
 
 1
 


 
 jsp
 org.apache.jasper.servlet.JspServlet
 
 fork
 false
 
 
 xpoweredBy
 false
 
 3
 


 
 default
 /
 

 
 jsp
 *.jsp
 *.jspx
 

   
 KKAuthorizationFilter

com.kodekonveyor.realm.KKAuthorizationFilter
   

   
 KKAuthorizationFilter
 /*
 REQUEST
   

 
 30
 










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



Re: Acessing static content - Tomcat 7 vs. Tomcat9

2019-10-07 Thread tomcat

Hi.
see at end.

On 07.10.2019 16:26, Martin Knoblauch wrote:

On Mon, Oct 7, 2019 at 3:31 PM Konstantin Kolinko 
wrote:


пн, 7 окт. 2019 г. в 15:44, Martin Knoblauch :


Hi Konstantin,

On Mon, Oct 7, 2019 at 2:36 PM Konstantin Kolinko <

knst.koli...@gmail.com>

wrote:


2. For Tomcat to issue a redirect, the "docs" directory must be

present in your web application. It can be empty, but it must be
present. (If there is none, Tomcat does not know that the requested
resource is a directory).



OK. The "docs" directory is actually a symbolic link to a directory
elsewhere.


Symbolic links by default are not allowed inside a web application.
The option to allow them differs between Tomcat 7 and 8.0, due to a
different underlying implementation of Web Application resources.

http://tomcat.apache.org/migration-8.html#Web_application_resources

(As a reminders: symbolic links must never be enabled on a
case-insensitive filesystem such as used by Windows, as it disables
the necessary security checks.)

http://tomcat.apache.org/tomcat-9.0-doc/security-howto.html

Best regards,
Konstantin Kolinko



OK, this is interesting. We still had the TC7 style "allowLiniking" in the
Context tag. Now moved to Resources.

I also added the two mapper directives to Context:

   

..
..
..

 


What I now get is weird in another way. But maybe it gives a hint:

[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "POST /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:10 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"
[07/Oct/2019:16:10:11 +0200] [0 ms] #160.46.219.110# - "GET /cb2/docs
HTTP/1.1" s:302 l:219 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384 #"Mozilla/5.0
(X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0"

Re: user and certificate info is not passed to tomcat

2019-10-07 Thread tomcat

On 07.10.2019 17:36, Magosányi Árpád wrote:

Magosányi,


How are you getting the attributes from the request?



This is the filter code:




String user = httpRequest.getRemoteUser(); Object cert =
httpRequest.getAttribute("javax.servlet.request.X509Certificate");
this.context.log("user:"+user);


This won't show any username unless the user has logged-in using HTTP
Basic/Digest authentication. Are you using those?


I am using openid right now in the apache side, but also tested with
basic auth to make sure that it is not an interaction with mod_openidc.

The user information does not get passed along either in the remoteUser
attribute or anywhere, in either of those cases, in spite that the
documentation states that the authenticated user name should be
retrievable using httpRequest.getRemoteUser(), and the CGI clearly shows
that we indeed have a REMOTE_USER in the apache side.




To get the certificate chain, I think you also need this in your httpd
configuration:

 JkOptions +ForwardSSLCertChain


I have added this now, though as I understand this is only needed if I
want to get the full chain.

Unfortunately this did not improve the situation in any way.



Forgot the atribute 'tomcatAuthentication="false"' in the Connector ?



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



Re: Acessing static content - Tomcat 7 vs. Tomcat9

2019-10-07 Thread tomcat

On 07.10.2019 13:45, Mark Thomas wrote:

On 07/10/2019 12:22, Martin Knoblauch wrote:

Dear fellow Tomcat users,

  recently we migrated our application from Tomcat7 to Tomcat9. Most things
work great so far, but we observed on issue. Basically serving static pages
has stopped for us.

  Our setup is Tomcat (7.0.62 or 9.0.12) behind Apache HTTPD (2.4.41 using
mod_jk 1.2.46). Yes, 9.0.12 is not recent, but we are forced to that
version.

The mod_jk configuration basically looks like:


   LoadModule jk_module modules/mod_jk.so

   JkWorkersFile "conf/cb2/workers.properties"
   JkShmFile "logs/jk-runtime-status"
   JkLogFile "logs/mod_jk.log"
   JkLogLevel info
   JkWatchdogInterval 60


And then later inside a virtual host:

#
# CB2 - Portal
#
# Mount the "/cb2" application to worker "cb2"
#
 JkMount /cb2/* cb2
#
# Unmount "/cb2/docs" from worker "cb2" to allow static content
# beeing served by apache. Same for "/cb2/cgi-bin"
#
 JkUnMount /cb2/docs/* cb2

So we JkUnMount the "/cb2/docs" directory from the application base in
order to server the content directly from Apache. "docs" itself is a
symbolic link pointing outside the application base.

With TC7, we observe the following in the apache access_log:

[07/Oct/2019:12:30:47 +0200] [2 ms] 160.46.219.110 - "POST /cb2/docs
HTTP/1.1" s:302 l:- S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384
[07/Oct/2019:12:30:47 +0200] [20 ms] 160.46.219.110 - "GET /cb2/docs/
HTTP/1.1" s:200 l:6367 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384

So the POST from the application is redirected to the static content, which
is served OK.

With TC9 we see:

[05/Oct/2019:02:58:13 +0200] [0 ms] #160.46.219.110# - "GET /docs HTTP/1.1"
s:404 l:196 S:TLSv1.2 C:ECDHE-RSA-AES256-GCM-SHA384


Where and how is the redirect generated?


As said, the major difference between the setups is TC7 vs. TC9. Any ideas
for me to follow? I did not find anything in the migration 7->8 or 8->9
guides.


I can't think of anything and a review of the migration guides doesn't
bring anything to mind. I'd be looking more at configuration differences
between the old and new systems at this point.

Mark



The URLs appear different :

- the first case shows a URL of "/cb2/docs" (with some kind of redirect from POST to a 
GET). According to the mod_jk configuration, this is NOT being proxied to Tomcat. Assuming 
thus that the httpd DOCUMENT_ROOT is set to (e.g.) /var/www/docs, it would mean that the 
file being served is some directory list (or index document) located below 
/var/www/docs/cb2/docs/ (on the httpd host).


- the second example shows a URL of "/docs", which according to the mod_jk configuration 
above is also NOT being proxied to Tomcat; thus Apache httpd attempts to serve it locally.
But that URL does not match any Apache-httpd-local file (because /var/www/docs/docs does 
not exist), and thus results in a 404 status "not found".


To verify this is quite simple :
In the URL bar of a browser, enter the URL "http://yourservername/cb2/docs; directly, 
replacing "yourservername" alernatively with the one for tomcat 7 and the one for tomcat9.
The result should be the same, because this URL is not being proxied to Tomcat, and is 
served locally by httpd.


(On the other hand, the URL "/docs" should give "404 not found" in both cases 
too)

What I suspect is :

The above URL "/cb2/docs" is not being entered in the browser URL bar.  Instead, the link 
to that URL occurs in a html page previously returned by Tomcat, and the user just clicks 
on the link.
Then maybe it is that previous page returned by Tomcat, that is different between Tomcat 7 
and Tomcat 9.

(That could be consistent with "the major difference between the setups is TC7 vs. 
TC9.").

Further speculation under incomplete information (I love this) : could it be that under 
Tomcat 7, your application is deployed under ../webapps/cb2, while under tomcat 9, you 
have relocated it to ../webapps/ROOT ?



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



Re: SSO fails on Tomcat 9

2019-09-10 Thread tomcat

On 10.09.2019 15:38, Mark Thomas wrote:

On 06/09/2019 13:20, Heidi Leerink - Duverger wrote:

Hello Mark,

That helps somewhat, my browser now shows the login page for our application, 
BUT I do not get my username in HTTP variable REMOTE_USER but the principal 
keytab related name.

So instead of hduverge I get HTTP/nlsl-decadetst.u4agr.com@U$AGR.COM


The Tomcat Authenticator takes care of validating the user. In the
configuration you provided the JAASRealm is - effectively -
(re-)validating the contents of the keytab file. That is why you see the
keytab principal as the authenticated user.

Try replacing the JAASRealm with the AuthenticatedUserRealm. Something like:

   

Mmm. That looks like a typo, likely to confuse this OP even more, no ?



Note: This Realm should *only* be used with Authenticators like
org.apache.catalina.authenticator.SpnegoAuthenticator that authenticate
the user since this Realm simply takes the information provided and
assumes it is valid.

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: POST request fails if content is ignored?

2019-09-09 Thread tomcat

On 09.09.2019 15:21, Leon Atherton wrote:

Thank you for the suggestion.

I have just tried playing with this value. Setting it to -1, and setting
it to 100x larger than the default.
In both cases, the behaviour seems unchanged.

Without touching this value, Tomcat will accept multipart POST requests
much larger than 2MB (which is the default) as long as you call
request.getPart() or request.getParameter().


I haven't tried that, but as per the documentation that at least looks wrong.



The problem I am seeing is that if a response is sent without calling
one of those methods, the browsers see it as a failed request.


To help me (or us) better understand the issue, could you provide a bit of 
context ?
Such as : why would the client send content in a POST, if the service at the end of the 
target URL is not going to read that content ?

What would be a use case ?

(Mainly because my interpretation is that, if the browser does that, then at least in some 
way it /is/ a bad request, which /should/ fail).


And maybe another question : have you tried monitoring such a request/response using a 
browser-based tracing tool, to show exactly what the server is sending back ?

(is it e.g. some kind of 4xx response ?)




Thanks

On 09/09/2019 12:59, André Warnier (tomcat) wrote:

Hi.
Did you check :
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes

--> maxPostSize

Note : normally, the browser will encode (Base64 or similar) the
content of a file and send the encoded content, which tends to be
significantly larger (in bytes) than the original file (say + 30%). I
do not know (and the doc does not say) if the maxPostSize attribute
refers to the POST content still encoded or already decoded.


On 09.09.2019 12:53, Leon Atherton wrote:

Hello,

I've discovered an interesting issue where POST requests fail when
uploading a file over about ~6MB if the server ignores the request
content.

I've put together a simple project to reproduce it:
https://github.com/leonatherton/tomcat-request-issue

Serverside code:
https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java

Clientside code:
https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html


If you'd like to try it yourself there are a couple of pre-built war
files on the releases page, and there are steps to reproduce in the
README.md file.

The problem does not occur when uploading a small file, and the problem
can be "fixed" by simply getting a parameter from the request object. It
reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara,
but I am seeing similar on Jetty.

My guess is that the server responds before the client has finished
uploading the file. The browsers see the incomplete upload and report
this as an error, despite content being sent in response. And my guess
is that inspecting a request parameter causes the server to wait for the
full upload before sending the response.

It's a slightly odd workflow, but it's not too unreasonable to sometimes
respond early and ignore the request content.

Is this expected behavior, or a bug in Tomcat?

Thanks!
Leon

-
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: POST request fails if content is ignored?

2019-09-09 Thread tomcat

Hi.
Did you check :
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Common_Attributes
--> maxPostSize

Note : normally, the browser will encode (Base64 or similar) the content of a file and 
send the encoded content, which tends to be significantly larger (in bytes) than the 
original file (say + 30%). I do not know (and the doc does not say) if the maxPostSize 
attribute refers to the POST content still encoded or already decoded.



On 09.09.2019 12:53, Leon Atherton wrote:

Hello,

I've discovered an interesting issue where POST requests fail when
uploading a file over about ~6MB if the server ignores the request content.

I've put together a simple project to reproduce it:
https://github.com/leonatherton/tomcat-request-issue

Serverside code:
https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/java/DemoServlet.java
Clientside code:
https://github.com/leonatherton/tomcat-request-issue/blob/master/src/main/webapp/index.html

If you'd like to try it yourself there are a couple of pre-built war
files on the releases page, and there are steps to reproduce in the
README.md file.

The problem does not occur when uploading a small file, and the problem
can be "fixed" by simply getting a parameter from the request object. It
reproduces in Tomcat 8 & 9. The problem does not reproduce on Payara,
but I am seeing similar on Jetty.

My guess is that the server responds before the client has finished
uploading the file. The browsers see the incomplete upload and report
this as an error, despite content being sent in response. And my guess
is that inspecting a request parameter causes the server to wait for the
full upload before sending the response.

It's a slightly odd workflow, but it's not too unreasonable to sometimes
respond early and ignore the request content.

Is this expected behavior, or a bug in Tomcat?

Thanks!
Leon

-
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.45 service error 1067

2019-09-08 Thread tomcat

Hello Jason.
Have a look at the archives of this mailing list, for the last 30 days or so.
I think that there have been some issues with the tomcat(x).exe wrapper 
recently.
And I believe (but don't trust me entirely on this) that one quick workaround was to copy 
the previous tomcat8.exe program on top of the one recently installed, and try again.



On 08.09.2019 21:45, Jason Wong wrote:

Hi.

I have an application running on tomcat 8.0.53 (32-bit) running on windows 
2008R2 server (64-bit), it runs fine.

I'm looking to upgrade to tomcat 8.5.45 (32-bit). I downloaded the 
apache-tomcat-8.5.45.exe installer, verified the signature, and ran it (no 
errors).

But when try to start the 8.5.45 service, it crashes immediately with:

Windows could not start the Apache Tomcat 8.5 Tomcat85 service on Local 
Computer.
Error 1067: The process terminated unexpectedly.

Not much in the log files:

commons-daemon log

[2019-09-08 14:50:06] [debug] ( prunsrv.c:1754) [ 1952] Apache Commons Daemon 
procrun log initialized.
[2019-09-08 14:50:06] [info]  ( prunsrv.c:1758) [ 1952] Apache Commons Daemon 
procrun (1.2.0.0 32-bit) started.
[2019-09-08 14:50:06] [info]  ( prunsrv.c:1668) [ 1952] Running Service 
'Tomcat85'...
[2019-09-08 14:50:06] [debug] ( prunsrv.c:1441) [ 2460] Inside ServiceMain...
[2019-09-08 14:50:06] [debug] ( prunsrv.c:904 ) [ 2460] reportServiceStatusE: 
dwCurrentState = 2, dwWin32ExitCode = 0, dwWaitHint = 3000, 
dwServiceSpecificExitCode = 0.
[2019-09-08 14:50:06] [info]  ( prunsrv.c:1196) [ 2460] Starting service...

tomcat stderr log

2019-09-08 14:50:06 Apache Commons Daemon procrun stderr initialized.

tomcat stdout log

2019-09-08 14:50:06 Apache Commons Daemon procrun stdout initialized.

I uninstalled, downloaded again, reinstalled, but the same thing happens.

One thing I find strange is that if I run my application using startup.bat in 
the tomcat 8.5.45 bin folder, it runs just fine.

I'm using the same jvm.dll that my tomcat 8.0.53 service uses. I've tried a 
couple other jre versions but have the same problem.

The windows event viewer has some additional error messages (below).

I've searched with google but I can't find anything that could help.

Any ideas?

Thanks.


Faulting application name: Tomcat85.exe, version: 1.2.0.0, time stamp: 
0x5d15f1ac
Faulting module name: ntdll.dll, version: 6.1.7601.24511, time stamp: 0x5d3fa86b
Exception code: 0xc005
Fault offset: 0x00038120
Faulting process id: 0x17c
Faulting application start time: 0x01d56673e1d91ab6
Faulting application path: C:\Apache Software Foundation\Tomcat 
8.5_Tomcat85\bin\Tomcat85.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 200ff770-d267-11e9-ad87-00505681




Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: Tomcat85.exe
P2: 1.2.0.0
P3: 5d15f1ac
P4: ntdll.dll
P5: 6.1.7601.24511
P6: 5d3fa86b
P7: c005
P8: 00038120
P9:
P10:

Attached files:

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_Tomcat85.exe_1689eaa6183aaaf7cf6e93c94c2e1f6eadf2bfd_04e7a9d6

Analysis symbol:
Rechecking for solution: 0
Report Id: 200ff770-d267-11e9-ad87-00505681
Report Status: 4


Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: Tomcat85.exe
P2: 1.2.0.0
P3: 5d15f1ac
P4: ntdll.dll
P5: 6.1.7601.24511
P6: 5d3fa86b
P7: c005
P8: 00038120
P9:
P10:

Attached files:

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_Tomcat85.exe_1689eaa6183aaaf7cf6e93c94c2e1f6eadf2bfd_04e7a9d6

Analysis symbol:
Rechecking for solution: 0
Report Id: 200ff770-d267-11e9-ad87-00505681
Report Status: 0








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



Re: Reg : Parameter Filters

2019-09-06 Thread tomcat

On 05.09.2019 20:58, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Praveen,

On 9/5/19 05:07, praveen kumar wrote:

Hello, I am working with an application called geoserver which
works on Apache Tomcat server. Just for an idea for those who donot
know, geoserver is an application that serves web map services.
When I am calling this service I will be providing a few parameters
about the map like layer name, height, width and so on.., Now my
requirement is to restrict the values passed to these parameters
Like for example for WIDTH it should only consider an integer, if a
request having a string for WIDTH should not reach my application.
I am looking for some redirect rules but I could not succeed. It
would be great if some one can help or guide me on this.


LOL this service doesn't actually sanitize its input? Yikes.

The good news is that you can do this in a few ways.

You have 3 options that I can see:

1. Use a redirect filter
2. Use a reverse-proxy like Apache with some filtering configured
3. Write it yourself

In order to use a redirect filter, you will have to:

a. Choose a redirect filter (e.g. Tomcat's rewrite[1] or Tuckey's
urlrewrite[2])
b. Configure it with a file. The configuration depends upon which
filter you choose
c. Bundle that filter+config with the application

In order to use a reverse proxy, you'll need to:

a. Choose a reverse proxy (e.g. Apache httpd, nginx, Squid, etc.)
b. Configure it properly (which depends upon your choice in (a) above)

In order to write it yourself, you will have to:

a. Write a servlet filter in Java
b. Package that filter into the application
c. Install that filter into the filter-chain by modifying the
application's WEB-INF/web.xml file

Do you have a preference?

- -chris


+1, but I would have to add that first of all, Praveen should have a clear idea of /what 
he thinks should happen/, if one of the request parameters does not meet expectations.
Saying that "the request should not make it to the application" is one thing, but what do 
you want to happen instead ?




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



Re: SSO fails on Tomcat 9

2019-09-06 Thread tomcat

Hi Heidi.

We have kind of a conundrum here :

- Mark (who is one of the main tomcat developers) tested the SPNEGO (Kerberos) 
authentication under both tomcat8 and tomcat9, using the standard instructions provided in 
the respective on-line tomcat documentation pages, and reported that it works in both cases.


- You report that your installation works with tomcat8, but not with tomcat9, and that you 
are using the same infrastructure and the same parameters in both cases.

(Someone else also reported a case with problems with tomcat9).

- The description of your problem (and the tomcat9 logfiles) seems to indicate a problem 
with the Kerberos "pre-authentication".

(These lines of the log :

>>>KRBError:
...  error code is 25
 error Message is Additional pre-authentication required
)

And based on my own previous experience with Windows authentication in general (but not 
Kerberos), it is also my impression that your problem is at the Kerberos level, not really 
at the tomcat level.
I have looked for "Kerberos Additional pre-authentication required" in the www, and 
despite the fact that I do not really know Kerberos, it seems that the error message above 
indicates that your browser and the server cannot even agree between them, to actually 
start exchanging Kerberos tokens (keys) between them, to complete a Kerberos authentication.
(And that may be why you see a single 401 response in your logs, and why SPNEGO 
immediately concludes that the user is not authenticated).


(There are also lines in that logfile, which seem to hint at some DNS (name resolution) 
issue, but that may be a false alarm or a secondary issue).


One way to reconcile the above conflicting information, would be if for example some 
SPNEGO Valve parameter, in your configuration, would be unspecified and defaulting to some 
value in your case, and a different value in Mark's case.
(Or vice-versa, that you are specifying a value, and Mark is using the default, and the 
result is not the same.)
Another possibility would be that the available (or default) encryption methods are 
different between tomcat8 and tomcat9 (or between different browsers), and that in your 
case and Mark's, the browser and the server arrive at different encryption choices and 
cannot agree on a common one.


It may be useful for you and Mark to compare in detail, the settings which you use for the 
SPNEGO Valve (and/or for encryption ?).


Another very vague (and maybe wrong) suspicion that I would have is based on 
some questions :
- does the tomcat hostname play a role in the Kerberos authentication ?
- if yes, does the SPNEGO Valve obtain this name via some ".getServerName()"-like method, 
whose result may be different under tomcat8 and tomcat9 in some circumstances ?




On 05.09.2019 22:10, Heidi Leerink - Duverger wrote:

Hello Mark,

I have spent a lot of time comparing both T8 and T9 installations on de 
nsl-decadetst.u4agr.com PC.
Sorry but I can't find a major difference in the conf file, apart from 
differences Tomcat itself came with in the conf files.
The stdout is mainly the same and the stderr show in Tomcat 8 hduverge 
authenticated and in Tomcat 9 not authenticated.
I'm lost now I have no ideas left where to look for differences or how to find 
a solution for this major issue.
Attached once again the files from our Tomcat 8 and Tomcay 9 installation.

Met vriendelijke groeten van
Heidi Leerink - Duverger
Technisch Consultant

Met vriendelijke groeten van
Heidi Leerink - Duverger
Technisch Consultant


In business for people.
Unit4 Business Software Netherlands B.V.
Papendorpseweg 100, 3710 BJ Utrecht, Netherlands
T  +31 88 247 1444
E  heidi.duver...@unit4.com
This message and any attachment(s) are intended only for the use of the named 
recipient and may contain information that is privileged, confidential or 
otherwise exempt from disclosure under applicable law. If you are not the 
intended recipient, please notify the sender by return e-mail and delete this 
message from your system. Do not disclose the contents of this document to any 
other persons. Violation of this notice may be unlawful. Please note that 
internet communications are not secure and e-mails are susceptible to change. 
Thank you for your cooperation.

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: woensdag 4 september 2019 11:09
To: users@tomcat.apache.org
Subject: Re: SSO fails on Tomcat 9

Heidi,

I have just completed the tests and SPNEGO works as expected with both Tomcat 
8.5.x and 9.0.x.

The test environment was as per:
https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fwindows-auth-howto.htmldata=01%7C01%7Cheidi.duverger%40unit4.com%7Cc8223b9bd1f34f08008608d731178dde%7Cee137cc45d4343cf9da5f75728b8d21f%7C1sdata=I%2BJLU837vV78VExqcHdf5Z5MYat2HDEPbNKvpsmq6%2FE%3Dreserved=0

with the following changes:
- Updated the Domain Controller 

Re: Fw: Tomcat 7.0 how to check if overloaded with requests or were requests received by tomcat on a specific day and time

2019-09-04 Thread tomcat

On 04.09.2019 08:11, ford royal wrote:



Dear Experts

Please guide me I am trying to investigate we use TOMCAT 7.0

1. how to check if TOMCAT is overloaded with incoming requests ?
2. were the requests received by TOMCAT on a specific day and time from SAP ECC 
? How to
find ?



Precise tomcat version ? (7.x.y)
Precise JVM versions ?
Precise platform (OS) ?

1. The first step would be to see if it is not the platform that is overloaded.
You can get an idea of that with e.g. "top" (for Linux) or the Task Manager 
(for Windows).
Tomcat (or rather the JVM which runs Tomcat) will use as much CPU as it can get.
If it is the only serious thing running on that system, then it will use 100% of the CPU, 
if it can/must, to process incoming requests.


2. Configure a tomcat access log, and look at it. In the standard configuration, it will 
show the IP of the client, and the requested URL, for each request. It probably also shows 
the time needed to process each request. See here :

http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Access_Log_Valve


Also, tomcat 7 is old, and the current version is tomcat 9.
You'll have more chances to get better answers with a more recent version.



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



Re: SSO fails on Tomcat 9

2019-09-03 Thread tomcat

Hi.
See below.

On 03.09.2019 11:56, Heidi Leerink - Duverger wrote:

Hello Alex,

Thank you for the extensive answer.

Q1: Are you sure that it is *exactly* the same ?
Yes the installation is done on the same PC with the same user principal for 
the Tomcat service to log in .
The Tomcat 8 service is stopped during the Tomcat 9 test.
We had the exact same problem when installing in a test environment at one of 
our Customer sites. Most of our customers that are using SSO with our 
application are still using Tomcat 8 with no problems and all with the same 
spnego config.
My colleague initially set up this Tomcat 9 installation using a few tomcat 9 
versions ( .8 .20 and .24). I myself, reinstalled and configured Tomcat 9.024 
from scratch, with no success and always the same results.



Q3: Is the PC where you are using the browser to test, also the same one where Tomcat is 
installed ?
(I am not sure that this type of authentication should work, if the same machine is at the 
same time the client and the server)
In any case, it may be a good idea if you tested the same access, with a browser on 
another PC workstation.



Q2: when "it does not work", does the browser popup a login dialog ?
Yes I have seen that one be not with the recent config.
Browser response :

Google Chrome
This site can't be reachedThe webpage at http://nlsl-decadetst:8787/apex42a/ 
might be temporarily down or it may have moved permanently to a new web address.
ERR_INVALID_RESPONSE

Internet Explorer 11:
Can't reach this page
.Make sure the web address http://nlsl-decadetst:8787 is correct
.Search for this site on Bing
.Refresh the page
More information  More information
The connection to the website was reset.
Error Code: INET_E_DOWNLOAD_FAILURE



Both of the errors above indicate more a DNS or TCP issue, than a tomcat or authentication 
issue.
(As shown, they indicate that the browser can either not find the server "nlsl-decadetst", 
or cannot make a TCP connection to "nlsl-decadetst:8787")


On the same workstation PC where you are doing these tests, can you
a) open a command window
b) enter : nslookup nlsl-decadetst
c) tell us what the response is ?
d) enter : nslookup nlsl-decadetst.u4agr.com
e) tell us what the response is ?


(attachements the most recent stderr and stdout)



Unfortunately, I am no Kerberos specialist and cannot tell you what the messages in the 
log really mean.

But the following (from the stderr) should probably be investigated further :
>>>KRBError:
 sTime is Tue Sep 03 11:47:29 CEST 2019 1567504049000
 suSec is 329207
 error code is 25
 error Message is Additional pre-authentication required
 sname is krbtgt/u4agr@u4agr.com
 eData provided.
 msgType is 30

That seems to indicate that something is not working as expected, at the 
Kerberos level.


Note : why it would work with tomcat8 and not with tomcat9 is still not clear to me, 
unless there have been some changes between the tomcat8 SPNEGO Valve and the tomcat9 
SPNGEGO Valve, or else maybe in terms of the tomcat hostname considerations.




I know off Fiddler2 but never used it before, I will try to set that up...


Met vriendelijke groeten van
Heidi Leerink - Duverger
Technisch Consultant


In business for people.
Unit4 Business Software Netherlands B.V.
Papendorpseweg 100, 3710 BJ Utrecht, Netherlands
T  +31 88 247 1444
E  heidi.duver...@unit4.com
This message and any attachment(s) are intended only for the use of the named 
recipient and may contain information that is privileged, confidential or 
otherwise exempt from disclosure under applicable law. If you are not the 
intended recipient, please notify the sender by return e-mail and delete this 
message from your system. Do not disclose the contents of this document to any 
other persons. Violation of this notice may be unlawful. Please note that 
internet communications are not secure and e-mails are susceptible to change. 
Thank you for your cooperation.

-Original Message-
From: André Warnier (tomcat) [mailto:a...@ice-sa.com]
Sent: dinsdag 3 september 2019 10:39
To: users@tomcat.apache.org
Subject: Re: SSO fails on Tomcat 9

Hello Heidi.

Thank you for the complete information provided in your post below.

I do not have any experience with the Tomcat SPNEGO Valve per se, but quite a 
bit of experience with Windows Integrated Authentication.
To me, the symptoms that you describe below, do not really look like a problem 
at the Tomcat level, but more like a problem between the browser and the 
Windows authentication in general.

See notes and questions in the text below.

On 02.09.2019 12:35, Heidi Leerink - Duverger wrote:

We have the following problem with connecting from the tomcat
environment 9.024 with the Active Directory of Windows, Kerberos
database. (win2008 DC's)

In Tomcat's log files, with Tomcat8, which gives no problems, it is
connected to the Active directory.

It i

  1   2   3   4   5   6   7   8   9   >