Registration open for Community Over Code North America

[Rich Bowen]

Hello! Registration is still open for the upcoming Community Over Code
NA event in Halifax, NS! We invite you to  register for the event
https://communityovercode.org/registration/

Apache Committers, note that you have a special discounted rate for the
conference at US$250. To take advantage of this rate, use the special
code sent to the committers@ list by Brian Proffitt earlier this month.

If you are in need of an invitation letter, please consult the
information at https://communityovercode.org/visa-letter/

Please see https://communityovercode.org/ for more information about
the event, including how to make reservations for discounted hotel
rooms in Halifax. Discounted rates will only be available until Sept.
5, so reserve soon!

--Rich, for the event planning team

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

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le jeu. 24 août 2023 à 13:06, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Daniel,
>
> On 8/23/23 13:03, Daniel Savard wrote:
> > I didn't specify the actual Tomcat version because the problem occurs
> under
> > all versions. We are running a commercial web application and all of
> sudden
> > after a while Tomcat is crashing without issuing any message. It is very
> > likely due to the application. But the vendor was of no help to solve
> this
> > problem which has existed for a long time. I suspect something like
> > insufficient memory allocated to the VM or something like that. Is there
> > anything I can do to gather more information on the root cause of this
> > issue?
> >
> > Tomcat is running as a service and is restarted automatically if it
> > crashes. Again, the problem is very unlikely to be with Tomcat itself,
> but
> > the tuning of the VM.
>
> What kind of environment (e.g. Windows vs UNIX, etc.)? What is running
> the service? Are there log files for the service which are different
> than usual (e.g. syslog vs catalina.out)?
>
> What are your memory settings, and how much physical RAM do you have?
>
> It's unlikely that the JVM is just disappearing without leaving any
> trace. If you are on Linux, maybe you are the victim of oome-killer?
> That will show in the syslog with a whole lot of output. Search syslog
> for "oom" and you will probably find it right away if that's the cause.
>
> -chris
>

Hi Chris,

Thanks for the answer.  It is running on Windows and it is running as a
service which is configured to restart if it fails. No different log files
at my knowledge except application logs.

There is 14 GB physical RAM on this server. Initial memory pool is 4 GB and
maximum memory pool is 8 GB.

Well, the only thing I can say is Tomcat is failing at some point and
shutting itself down or being shutdown or killed, I cannot say the JVM
itself gets killed.

-
Daniel Savard

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le mer. 23 août 2023 à 13:16, Robert Turner  a écrit :

> You can try adding:
>
> -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=C:\HeapDump\java_pid.hprof
>
> to the Java options (in "Configure Tomcat") to capture heap dumps on out of
> memory errors (adjust path to suit your configuration)
>
> Robert
>

Hi Robert,

I will look into it. For now, I cannot modify the system easily. I need to
plan a change for this with at least a one week notice and upon approval.
Will try to include this in a forthcoming change.

-
Daniel Savard

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le jeu. 24 août 2023 à 02:29, Thomas Hoffmann (Speed4Trade GmbH)
 a écrit :

> Hello Daniel,
>
> > -Ursprüngliche Nachricht-
> > Von: Daniel Savard 
> > Gesendet: Mittwoch, 23. August 2023 19:03
> > An: users@tomcat.apache.org
> > Betreff: Tomcat 9.0.x on Windows crashing
> >
> > Hi everyone,
> >
> > I didn't specify the actual Tomcat version because the problem occurs
> under
> > all versions. We are running a commercial web application and all of
> sudden
> > after a while Tomcat is crashing without issuing any message. It is very
> likely
> > due to the application. But the vendor was of no help to solve this
> problem
> > which has existed for a long time. I suspect something like insufficient
> > memory allocated to the VM or something like that. Is there anything I
> can
> > do to gather more information on the root cause of this issue?
> >
> > Tomcat is running as a service and is restarted automatically if it
> crashes.
> > Again, the problem is very unlikely to be with Tomcat itself, but the
> tuning of
> > the VM.
> >
> > -
> > Daniel Savard
>
> You can also watch out for a file named hs_err_pid
> If the JVM is crashing hard, it usually produces this file somewhere in
> the Tomcat folder.
>
> Greetings,
> Thomas
>

Thanks for the tip, there is no such file in the whole filesystem. So, the
JVM isn't crashing, but Tomcat is crashing.

-
Daniel Savard

RE: [External] Re: Supporting Proxy Protocol in Tomcat

[Amit Pande]

Oh, sure. So, what would be the best way to get some conclusion on this thread?

https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 The state of the ticket 
isn't updated for long. Perhaps add comments/ask the folks on user list to vote?

Thanks,
Amit

-Original Message-
From: Mark Thomas  
Sent: Monday, August 28, 2023 11:20 AM
To: Tomcat Users List 
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



28 Aug 2023 17:11:20 Amit Pande :

> Mark,
>
> Just checking - Did this issue get discussed in any of the core 
> members' meeting?

There are no such meetings. Discussion happens on the mailing lists.

Mark


>
> Thanks,
> Amit
>
> -Original Message-
> From: Amit Pande
> Sent: Monday, July 31, 2023 9:29 AM
> To: Tomcat Users List 
> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>
> Yes, understood.
>
> Thank you for clarifying. Even I was referring to initial consensus 
> without any timeline or approach conclusion.
>
> Thanks,
> Amit
>
> -Original Message-
> From: Mark Thomas 
> Sent: Friday, July 28, 2023 2:48 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> On 28/07/2023 19:21, Amit Pande wrote:
>> Thank you all for the valuable discussion on this topic.
>>
>> Is it okay to say that we're agreeing to adding proxy protocol 
>> support in Tomcat?
>
> I think that is a little too strong. At this point there is a proposed 
> approach and no one is objecting but until there is an actual patch to 
> discuss...
>
> Keep in mind that any committer can veto a change.
>
> My sense is that it should be possible to implement this feature while 
> addressing any concerns that may be raised but it is not guaranteed.
>
> Mark
>
>
>>
>> Thanks,
>> Amit
>>
>> -Original Message-
>> From: Christopher Schultz 
>> Sent: Thursday, July 27, 2023 4:13 PM
>> To: users@tomcat.apache.org
>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>
>> All,
>>
>> On 7/27/23 12:39, Mark Thomas wrote:
>>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
 On the topic of security, may we consider a trustedProxies setting?
>>>
>>> Seems reasonable.
>>
>> We should probably look at what httpd did for all of this.
>>
>> -chris
>>
   This
 would be an analog to the internalProxies setting on RemoteIpValve.
 It would need to be able to function with APR/NIO listening in a 
 Unix Domain Socket.

 I'm not sure if this is super useful, but the goal would be an 
 added layer of security to prevent Proxy Protocol header injection.

 On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas 
 wrote:

> On 26/07/2023 21:53, Christopher Schultz wrote:
>> Mark,
>>
>> On 7/26/23 13:58, Mark Thomas wrote:
>>> I'm not a huge fan of this feature in general. I prefer 
>>> supporting features backed by specifications rather than vendor 
>>> specific hacks.
>>
>> I think the PROXY protocol is fairly standard, even if it's not 
>> backed by an RFC. It's published by haproxy, but supported by 
>> nginx,
>> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
> https://ww/
> w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-client
> s
> -
> ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14
> f
> a
> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C638
> 2
> 6
> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V
> 2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpIL
> a
> 0
> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0
> ).
>
> ACK. That reduces my concerns somewhat.
>
>> Well, the reality is that people want to use this in the real 
>> world and this is essentially the only way to do it, barring 
>> coming up with a whole new protocol for the purpose (I'm looking 
>> at /you/ AJP!).
>
> Indeed.
>
>> So why not use /the/ protocol that (a) exists and (b) is 
>> supported by every single product that currently supports this 
>> type of thing?
>>
>>> My support for any patch is going to depend on the specifics of 
>>> the patch.
>>>
>>> In addition to the comments in the BZ
>>> - exposing the data as a request attribute is inconsistent with 
>>> other
>>>  mechanisms that solve the same problem (e.g. see
>>> RemoteIpFilter)
>>
>> +1
>>
>> The whole point of PROXY is to kind of mix-together the 
>> capabilities of both the RemoteIPFilter/Valve (which uses HTTP 
>> headers for
>> source-information) and the top-level idea of a Connector 

Re: [External] Re: Supporting Proxy Protocol in Tomcat

[Mark Thomas]

28 Aug 2023 17:11:20 Amit Pande :


Mark,

Just checking - Did this issue get discussed in any of the core 
members' meeting?


There are no such meetings. Discussion happens on the mailing lists.

Mark




Thanks,
Amit

-Original Message-
From: Amit Pande
Sent: Monday, July 31, 2023 9:29 AM
To: Tomcat Users List 
Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat

Yes, understood.

Thank you for clarifying. Even I was referring to initial consensus 
without any timeline or approach conclusion.


Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Friday, July 28, 2023 2:48 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat

On 28/07/2023 19:21, Amit Pande wrote:

Thank you all for the valuable discussion on this topic.

Is it okay to say that we're agreeing to adding proxy protocol support 
in Tomcat?


I think that is a little too strong. At this point there is a proposed 
approach and no one is objecting but until there is an actual patch to 
discuss...


Keep in mind that any committer can veto a change.

My sense is that it should be possible to implement this feature while 
addressing any concerns that may be raised but it is not guaranteed.


Mark




Thanks,
Amit

-Original Message-
From: Christopher Schultz 
Sent: Thursday, July 27, 2023 4:13 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat

All,

On 7/27/23 12:39, Mark Thomas wrote:

On 27/07/2023 16:27, Jonathan S. Fisher wrote:

On the topic of security, may we consider a trustedProxies setting?


Seems reasonable.


We should probably look at what httpd did for all of this.

-chris


  This
would be an analog to the internalProxies setting on RemoteIpValve.
It would need to be able to function with APR/NIO listening in a
Unix Domain Socket.

I'm not sure if this is super useful, but the goal would be an added
layer of security to prevent Proxy Protocol header injection.

On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas  
wrote:



On 26/07/2023 21:53, Christopher Schultz wrote:

Mark,

On 7/26/23 13:58, Mark Thomas wrote:

I'm not a huge fan of this feature in general. I prefer
supporting features backed by specifications rather than vendor 
specific hacks.


I think the PROXY protocol is fairly standard, even if it's not
backed by an RFC. It's published by haproxy, but supported by
nginx,
(obviously) haproxy, AWS, httpd[1], and a whole bunch of others (

https://ww/
w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients
-
ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f
a
b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382
6
0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
2
luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpILa
0
rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0
).

ACK. That reduces my concerns somewhat.


Well, the reality is that people want to use this in the real
world and this is essentially the only way to do it, barring
coming up with a whole new protocol for the purpose (I'm looking 
at /you/ AJP!).


Indeed.


So why not use /the/ protocol that (a) exists and (b) is supported
by every single product that currently supports this type of 
thing?



My support for any patch is going to depend on the specifics of
the patch.

In addition to the comments in the BZ
- exposing the data as a request attribute is inconsistent with
other
 mechanisms that solve the same problem (e.g. see
RemoteIpFilter)


+1

The whole point of PROXY is to kind of mix-together the
capabilities of both the RemoteIPFilter/Valve (which uses HTTP
headers for
source-information) and the top-level idea of a Connector
(something that binds to a socket and pushes bytes around).

The confusing thing here is that those two jobs are performed at
relatively different levels in Tomcat at the moment, as I
understand things.


Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
higher level because that is where they sit but the data originates
from the SocketWrapper.


If some kind of UberConnector could be built which essentially
does something like the following, it would be ideal:

public void accept(Socket s) {
 ProxyHeader proxyHeader = readProxyHeader(s);

 Connector realConnector = getRealConnector();

 realConnector.setRemoteIP(proxyHeader.getRemoteIP());
 realConnector.setRemotePort(proxyHeader.getRemotePort());

 realConnector.takeItAway(s);
}

I'm sure there are other pieces of information that would be good
to pass-through, but the identity of the remote client is the most
interesting one.


Yes, that is the general idea. Just a couple of minor tweaks to use
the SocketWrapper rather than the Connector and to do it in a
slightly different place. The Acceptor is too early as we want to
do as little as possible on the Acceptor thread.


- needs to be implemented for all Connectors


I hope not. The connectors should be able 

RE: [External] Re: Supporting Proxy Protocol in Tomcat

[Amit Pande]

Mark,

Just checking - Did this issue get discussed in any of the core members' 
meeting?

Thanks,
Amit

-Original Message-
From: Amit Pande
Sent: Monday, July 31, 2023 9:29 AM
To: Tomcat Users List 
Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat

Yes, understood.

Thank you for clarifying. Even I was referring to initial consensus without any 
timeline or approach conclusion.

Thanks,
Amit

-Original Message-
From: Mark Thomas 
Sent: Friday, July 28, 2023 2:48 PM
To: users@tomcat.apache.org
Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat

On 28/07/2023 19:21, Amit Pande wrote:
> Thank you all for the valuable discussion on this topic.
>
> Is it okay to say that we're agreeing to adding proxy protocol support in 
> Tomcat?

I think that is a little too strong. At this point there is a proposed approach 
and no one is objecting but until there is an actual patch to discuss...

Keep in mind that any committer can veto a change.

My sense is that it should be possible to implement this feature while 
addressing any concerns that may be raised but it is not guaranteed.

Mark


>
> Thanks,
> Amit
>
> -Original Message-
> From: Christopher Schultz 
> Sent: Thursday, July 27, 2023 4:13 PM
> To: users@tomcat.apache.org
> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>
> All,
>
> On 7/27/23 12:39, Mark Thomas wrote:
>> On 27/07/2023 16:27, Jonathan S. Fisher wrote:
>>> On the topic of security, may we consider a trustedProxies setting?
>>
>> Seems reasonable.
>
> We should probably look at what httpd did for all of this.
>
> -chris
>
>>>   This
>>> would be an analog to the internalProxies setting on RemoteIpValve.
>>> It would need to be able to function with APR/NIO listening in a
>>> Unix Domain Socket.
>>>
>>> I'm not sure if this is super useful, but the goal would be an added
>>> layer of security to prevent Proxy Protocol header injection.
>>>
>>> On Thu, Jul 27, 2023 at 3:47 AM Mark Thomas  wrote:
>>>
 On 26/07/2023 21:53, Christopher Schultz wrote:
> Mark,
>
> On 7/26/23 13:58, Mark Thomas wrote:
>> I'm not a huge fan of this feature in general. I prefer
>> supporting features backed by specifications rather than vendor specific 
>> hacks.
>
> I think the PROXY protocol is fairly standard, even if it's not
> backed by an RFC. It's published by haproxy, but supported by
> nginx,
> (obviously) haproxy, AWS, httpd[1], and a whole bunch of others (
 https://ww/
 w.haproxy.com%2Fblog%2Fuse-the-proxy-protocol-to-preserve-a-clients
 -
 ip-address=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f
 a
 b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382
 6
 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
 2
 luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=RWHWpILa
 0
 rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D=0
 ).

 ACK. That reduces my concerns somewhat.

> Well, the reality is that people want to use this in the real
> world and this is essentially the only way to do it, barring
> coming up with a whole new protocol for the purpose (I'm looking at /you/ 
> AJP!).

 Indeed.

> So why not use /the/ protocol that (a) exists and (b) is supported
> by every single product that currently supports this type of thing?
>
>> My support for any patch is going to depend on the specifics of
>> the patch.
>>
>> In addition to the comments in the BZ
>> - exposing the data as a request attribute is inconsistent with
>> other
>>  mechanisms that solve the same problem (e.g. see
>> RemoteIpFilter)
>
> +1
>
> The whole point of PROXY is to kind of mix-together the
> capabilities of both the RemoteIPFilter/Valve (which uses HTTP
> headers for
> source-information) and the top-level idea of a Connector
> (something that binds to a socket and pushes bytes around).
>
> The confusing thing here is that those two jobs are performed at
> relatively different levels in Tomcat at the moment, as I
> understand things.

 Yes and no. RemoteIP[Filter|Valve] insert/modify the data at a
 higher level because that is where they sit but the data originates
 from the SocketWrapper.

> If some kind of UberConnector could be built which essentially
> does something like the following, it would be ideal:
>
> public void accept(Socket s) {
>  ProxyHeader proxyHeader = readProxyHeader(s);
>
>  Connector realConnector = getRealConnector();
>
>  realConnector.setRemoteIP(proxyHeader.getRemoteIP());
>  realConnector.setRemotePort(proxyHeader.getRemotePort());
>
>  realConnector.takeItAway(s);
> }
>
> I'm sure there are other pieces of information that would be good
> to pass-through, but the identity of the 

Re: OT: where does JSTL set thsi cookie? javax.servlet.jsp.jstl.fmt.request.charset

[Ivano Luberti]

Progressing in my seach for a solution on how to deal with character 
encoding in Tomcat request and responses I have found this very useful link


https://cwiki.apache.org/confluence/display/TOMCAT/Character+Encoding

I thought it was sensible to mention here since is not in the 
traditional Tomcat docs but is nonetheles official documentation




-


Thank you all, and particularly to Thomas who pointed me to the answer.

Il 25/08/2023 18:09, Mark Thomas ha scritto:



On 25/08/2023 07:50, Ivano Luberti wrote:
Hi, I understand that this question can be OT but I don't know where 
to search for.


Looking into tomcat manager sessions I see this cookie set in each 
session



     javax.servlet.jsp.jstl.fmt.request.charset     ISO-8859-1


The value ISO-8859-1 i set even though the file encoding of the java 
launch option is set to UTF-8


There is someone who knows how JSTL decides the value of the cookie?

Or can you point me to some useful resource?


https://github.com/apache/tomcat-taglibs-standard/blob/main/impl/src/main/java/org/apache/taglibs/standard/tag/common/fmt/SetLocaleSupport.java#L138 



Mark

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


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: OT: where does JSTL set thsi cookie? javax.servlet.jsp.jstl.fmt.request.charset

[Ivano Luberti]

Thank you all, and particularly to Thomas who pointed me to the answer.

Il 25/08/2023 18:09, Mark Thomas ha scritto:



On 25/08/2023 07:50, Ivano Luberti wrote:
Hi, I understand that this question can be OT but I don't know where 
to search for.


Looking into tomcat manager sessions I see this cookie set in each 
session



     javax.servlet.jsp.jstl.fmt.request.charset     ISO-8859-1


The value ISO-8859-1 i set even though the file encoding of the java 
launch option is set to UTF-8


There is someone who knows how JSTL decides the value of the cookie?

Or can you point me to some useful resource?


https://github.com/apache/tomcat-taglibs-standard/blob/main/impl/src/main/java/org/apache/taglibs/standard/tag/common/fmt/SetLocaleSupport.java#L138 



Mark

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


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/