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 <users@tomcat.apache.org>
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 <ma...@apache.org>
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 <ch...@christopherschultz.net>
> 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 <ma...@apache.org> 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&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac14f
>>>> a
>>>> b5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6382
>>>> 6
>>>> 0892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
>>>> 2
>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RWHWpILa
>>>> 0
>>>> rLRM0xPgFAeXdk0y1l2ob%2BNcQHZP55fQDg%3D&reserved=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 to just have a thin
>>>>> layer in front of them "sipping" the header off the beginning of the 
>>>>> connection.
>>>>> I am *way* out of my depth here when it comes to Tomcat internals
>>>>> and so I don't want to appear to be telling you (Mark) "how it
>>>>> works/should work", but conceptually it "seems easy". That may not
>>>>> translate into "easy implementation" or it may mean "tons of
>>>>> refactoring that we wouldn't need if we didn't care that much."
>>>>
>>>> My point was that the provided patch only implements this for NIO.
>>>> It needs to implement it for NIO2 as well. APR/Native looks to be a
>>>> lot more difficult to implement and I'd be happy not implementing
>>>> it for APR/Native.
>>>>
>>>>>> - I'd expect it to look more like the SNI processing
>>>>>
>>>>> SNI processing is very connector-dependent, of course, because
>>>>> it's HTTPS-only. PROXY should allow HTTP, HTTPS, AJP, SFTP, JDBC, 
>>>>> anything.
>>>>> So if it can be implemented as something that can just "sit in
>>>>> front of"
>>>>> *any* connector now or in the future of Tomcat, that would be
>>>>> ideal. It could definitely be implemented as an "optional feature"
>>>>> on a Connector-by-Connector basis, but my sense is that it can be
>>>>> done separately and globally.
>>>>
>>>> Ah. You are thinking Connector as in protocol (HTTP, AJP, etc)
>>>> whereas I am thinking in terms of implementation (NIO, NIO2, etc).
>>>>
>>>> SNI is handled independently of implementation and I think PROXY
>>>> should be handled the same way. They also sit at almost the same
>>>> point in the processing (PROXY needs to be first). PROXY parsing
>>>> could be implemented within the existing handshake() method but I
>>>> think it would be much cleaner in a separate method.
>>>>
>>>> Without looking at it too closely I think the implementation would
>>>> look something like:
>>>>
>>>> - a new method on SocketWrapperBase that
>>>>      - checks if PROXY is enabled
>>>>      - returns immediately if PROXY is not enabled or has already
>>>>        been parsed
>>>>      - uses a new utility class (or classes) to parse the header
>>>>        (reading via the read() methods on SocketWrapperBase)
>>>>      - sets the cached values for remoteAddr, remoteHost,
>>>>        remotePort etc
>>>> - The SocketProcessor.doRun() implementations add a call to this new
>>>>      method just before the TLS handshake
>>>>
>>>> If we want to support the TLS information then a little additional
>>>> refactoring will be required (probably to cache the result of
>>>> SocketWrapperBase.getSslSupport) so the new utility classes can
>>>> insert a PROXY specific SSLSupport implementation.
>>>>
>>>>> Again, I'm speaking from a position of profound ignorance, here.
>>>>> Please don't hear me say "oh, this is easy, Mark... just go do it!"
>>>>> :)
>>>>
>>>> :)
>>>>
>>>> Actually with the patch that has already been provided and the
>>>> suggested implementation outline above I don't think there is too much 
>>>> work to do.
>>>>
>>>>>> Generally, I don't think implementing this is going to be
>>>>>> possible as some sort of plug-in.
>>>>>
>>>>> +1 Unless the plug-in is "a whole new set of protocol/endpoint/etc.
>>>>> handlers" which is a rather serious commitment.
>>>>
>>>> On reflection, with the approach above we probably could implement
>>>> this via a new plug-in framework but I am not sure it is worth the
>>>> effort at this point. Something to keep in mind if we have more
>>>> things wanting to integrate at this point in the processing chain.
>>>>
>>>> Mark
>>>>
>>>>>
>>>>> -chris
>>>>>
>>>>> [1]
>>>>> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html search for 
>>>>> "haproxy"
>>>>>
>>>>>> On 26/07/2023 17:44, Amit Pande wrote:
>>>>>>> Missed to ask this:
>>>>>>>
>>>>>>> Looking the patch, it involves modifying Tomcat code.
>>>>>>> Was wondering if it would be possible to refactor this patch
>>>>>>> and/or allow Tomcat core code to extend and plug-in the proxy
>>>>>>> protocol
>>>> support?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Amit Pande
>>>>>>> Sent: Wednesday, July 26, 2023 11:43 AM
>>>>>>> To: Tomcat Users List <users@tomcat.apache.org>
>>>>>>> Subject: RE: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Chris, Mark,
>>>>>>>
>>>>>>> Any thoughts on this?
>>>>>>>
>>>>>>> Mark, if we clean up the patch and re-submit, do you will have
>>>>>>> any concerns (specially security wise)?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Amit
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Jonathan S. Fisher <exabr...@gmail.com>
>>>>>>> Sent: Monday, July 24, 2023 12:41 PM
>>>>>>> To: Tomcat Users List <users@tomcat.apache.org>
>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>
>>>>>>> Just a side note, because we're also very interested in this patch!
>>>>>>>
>>>>>>> Awhile back, I was successfully able to apply this patch and
>>>>>>> terminate TCP/TLS using HaProxy. We then had Tomcat listen on a
>>>>>>> unix domain socket and the Proxy protocol provided *most *of the
>>>>>>> relevant/required information to tomcat. I believe we had to add
>>>>>>> a Valve to tomcat to set the Remote IP however as the patch
>>>>>>> didn't handle that case.
>>>>>>>
>>>>>>> I can find my notes from that experiment, but I do remember
>>>>>>> getting a significant boost in throughput and decrease in latency.
>>>>>>>
>>>>>>> +1 for this patch and willing to help out!
>>>>>>>
>>>>>>> On Mon, Jul 24, 2023 at 11:22 AM Amit Pande
>>>>>>> <amit.pa...@veritas.com.invalid>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thank you, Chris, again for inputs.
>>>>>>>> And sorry to circle back on this, late.
>>>>>>>>
>>>>>>>> One related question is - does it make sense to use the patch
>>>>>>>> attached in
>>>>>>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=57830 ?
>>>>>>>> And potentially, get it integrated into Tomcat versions?
>>>>>>>>
>>>>>>>> There are concerns from Mark about using the patch in its
>>>>>>>> current state, but I see last comment (#24) on the issue and
>>>>>>>> looks like there are some more points to be concluded.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Amit
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>> Sent: Wednesday, May 10, 2023 4:21 PM
>>>>>>>> To: users@tomcat.apache.org
>>>>>>>> Subject: Re: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>
>>>>>>>> Amit,
>>>>>>>>
>>>>>>>> On 5/10/23 12:59, Amit Pande wrote:
>>>>>>>>> Yes, we intended to have Tomcat run behind a (transparent) TCP
>>>>>>>>> proxy e.g.
>>>>>>>>>
>>>>>>>> https://www/.
>>>>>>>> envoyproxy.io
>>>> %2Fdocs%2Fenvoy%2Flatest%2Fintro%2Farch_overview%2Fother_
>>>>>>>> features%2Fip_transparency&data=05%7C01%7CAmit.Pande%40veritas.
>>>>>>>> c
>>>>>>>> om
>>>> %7Ca
>>>>>>>> 85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55b3eaca318e6ca
>>>>>>>> c
>>>>>>>> 32%7C0
>>>>>>>> %7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
>>>>>>>> j
>>>>>>>> AwMDAi
>>>>>>>> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
>>>>>>>> s
>>>>>>>> data=W
>>>>>>>> NEV4UQ5q4Nl8SEFHMz7C%2Fj3Qr7pCHpfyvQLeBn56uQ%3D&reserved=0
>>>>>>>> which supports the proxy protocol.
>>>>>>>>>
>>>>>>>>> Since there is not much action on this
>>>>>>>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F
>>>>>>>> %25
>>>>>>>> 2Fbz.a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C51dbcc5eeac
>>>>>>>> 1
>>>>>>>> 4fab5aa708db8ee67aae%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0
>>>>>>>> %
>>>>>>>> 7C638260892775883704%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
>>>>>>>> A
>>>>>>>> iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
>>>>>>>> &
>>>>>>>> sdata=PqTzx9i99HLy8g0qX0WpmWsW3sYDqkW0i522q74RApY%3D&reserved=0
>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.Pande%
>>>> 40veritas.com%7Ca85e610757b348137b4008db8c6d8156%7Cfc8e13c0422c4c55
>>>> b
>>>> 3eaca318e6cac32%7C0%7C0%7C638258174209955308%7CUnknown%7CTWFpbGZsb3
>>>> d
>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>>>> %
>>>> 7C3000%7C%7C%7C&sdata=mH7TRJny1YUOsG%2BeFXno4xdvsLAjz%2BRkQgCnLfehX
>>>> v Q%3D&reserved=0, does it imply that most of the times Tomcat is
>>>> running behind HTTP proxies and not TCP proxies?
>>>>>>>>> Or does it mean that, Tomcat or applications running in Tomcat
>>>>>>>>> does not
>>>>>>>> need the remote client address information?
>>>>>>>>
>>>>>>>> I can't speak for anybody else, but I use Apache httpd as my
>>>>>>>> reverse-proxy and I do terminate TLS. I also use it for
>>>>>>>> load-balancing/fail-over, caching, some authorization, etc. I
>>>>>>>> wouldn't be able to use a TCP load-balancer because I hide
>>>>>>>> multiple services behind my reverse-proxy which run in
>>>>>>>> different places. It's not just s dumb pass-through.
>>>>>>>>
>>>>>>>> Hope that helps,
>>>>>>>> -chris
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christopher Schultz <ch...@christopherschultz.net>
>>>>>>>>> Sent: Monday, May 8, 2023 3:40 PM
>>>>>>>>> To: users@tomcat.apache.org
>>>>>>>>> Subject: [External] Re: Supporting Proxy Protocol in Tomcat
>>>>>>>>>
>>>>>>>>> Amit,
>>>>>>>>>
>>>>>>>>> On 5/4/23 16:07, Amit Pande wrote:
>>>>>>>>>> We have a similar requirement as mentioned in the below
>>>>>>>>>> enhancement
>>>>>>>> request.
>>>>>>>>>>
>>>>>>>>>> https://bz/.
>>>>>>>>>> a%2F&data=05%7C01%7CAmit.Pande%40veritas.com%7C07ebe3c927ed4b
>>>>>>>>>> 7
>>>>>>>>>> 87206
>>>>>>>>>> 08
>>>>>>>>>> db519ccce8%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63819
>>>>>>>>>> 3
>>>>>>>>>> 50613
>>>>>>>>>> 56
>>>>>>>>>> 24269%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l
>>>>>>>>>> u
>>>>>>>>>> MzIiL
>>>>>>>>>> CJ
>>>>>>>>>> BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3UFyiGJ9Zgt
>>>>>>>>>> L
>>>>>>>>>> qUzY9
>>>>>>>>>> JM
>>>>>>>>>> CK2MfwKN3OAOKdr6JmTUGkPw%3D&reserved=0
>>>>>>>>>> pache.org
>>>> %2Fbugzilla%2Fshow_bug.cgi%3Fid%3D57830&data=05%7C01%7CAmit.
>>>>>>>>>> P
>>>>>>>>>> ande%40veritas.com%7Cab789327b86845e8ad7208db50046f55%7Cfc8e1
>>>>>>>>>> 3
>>>>>>>>>> c0422
>>>>>>>>>> c4
>>>>>>>>>> c
>>>>>>>>>> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CT
>>>>>>>>>> W
>>>>>>>>>> FpbGZ
>>>>>>>>>> sb
>>>>>>>>>> 3
>>>>>>>>>> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>>>>>>>>>> 6
>>>>>>>>>> Mn0%3
>>>>>>>>>> D%
>>>>>>>>>> 7
>>>>>>>>>> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl
>>>>>>>>>> 4
>>>>>>>>>> mY%3D
>>>>>>>>>> &r
>>>>>>>>>> e
>>>>>>>>>> served=0
>>>>>>>>>>
>>>>>>>>>> Is there any plan to add this support in Tomcat in future
>>>>>>>>>> releases?
>>>>>>>>>
>>>>>>>>> Nothing at the moment that I know of.
>>>>>>>>>
>>>>>>>>> I thought that markt had looked at this a while back and said
>>>>>>>>> it didn't
>>>>>>>> look too difficult. It does require Tomcat to handle the stream
>>>>>>>> directly and not just rely on Java's SSLServerSocket. I thought
>>>>>>>> that had been done at some point, but it may not have. Handling
>>>>>>>> the stream directly may have some other advantages as well,
>>>>>>>> though it definitely makes the code more complicated.
>>>>>>>>>
>>>>>>>>>> Also, since this was requested long time back and there is no
>>>>>>>>>> update, are there any other alternatives to pass the client
>>>>>>>>>> information from load balancer to Tomcat in situations where
>>>>>>>>>> there is no SSL termination at load balancer?
>>>>>>>>> You mean like a network load balancer where the lb is just
>>>>>>>>> proxying
>>>>>>>> bytes and not looking at the data at all? The PROXY protocol
>>>>>>>> really is the best way to do that, honestly.
>>>>>>>>>
>>>>>>>>> -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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jonathan | exabr...@gmail.com
>>>>>>> Pessimists, see a jar as half empty. Optimists, in contrast, see
>>>>>>> it as half full.
>>>>>>> Engineers, of course, understand the glass is twice as big as it
>>>>>>> needs to be.
>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> -
>>>>>>> ---- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>>>>>> -
>>>>>> --- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> -
>>>>> -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>>>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> 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

Reply via email to