RE: https redirect failed for POST request when behind a load balancer

[Bin Chen]

Peter:
Checked F5 and found that it was the proper behavior of F5 in this http to 
https redirect. There is a way to use iRule to change that.

Thank you very much!

Bin

-Original Message-
From: Kreuser, Peter [mailto:pkreu...@airplus.com] 
Sent: Wednesday, January 25, 2017 1:22 AM
To: Tomcat Users List 
Subject: AW: https redirect failed for POST request when behind a load balancer

Bin,





So it is working as designed in the RFC...



https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_HTTP-5F302=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ=Cd24gJffDyonEJHgpKqwRRHfhBVcnuh3ZXbrUn1wq6w=O-RpRIWcNXyjocbL9uVgxk9VkouVffRloYNsr1Jq7xM=
  -> 302 leads to a resend with GET.



If your client would speak HTTP/1.1, a 307 response code could be interpreted 
as preserving the request type as originally sent. It may be feasible to send 
this RC in a BigIP iRule for this specific URL. But it is still depending on 
the client implementation. And I have not seen this in the wild.



Now: how does the client get to the POST with http? If your app runs in a 
regular browser and uses relative URLs, upgrade the first request to https 
(probably a GET), then after that all links, forms will be on https.



Best regards



Peter

Re: HTTP response reason phrases

[Rémy Maucherat]

2017-01-24 20:08 GMT+01:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm cross-posting dev@ and users@, but please only reply to dev@ if
> you'd like to get involved in this discussion.
>
> I'd like to openly-discuss r1702765 [1]. There have been some
> complaints on both users@ and dev@ and some BZ issues filed against
> Tomcat 8.5 and 9.0 for removing the reason phrase. It happened in
> r1702765 with no referenced BZ issue and was first released with
> Tomcat 8.5.0 -- the initial release of Tomcat 8.5 -- as well as 9.0.0.M1
> .
>
> This issue doesn't really affect me, but some recent conversations
> about the "stability" (in terms of "things not changing") of Tomcat
> have me thinking about the implications of making this change in
> Tomcat 8.5.x and not in just Tomcat 9.0.x.
>
> It is well-known within this community that Tomcat 8.0.x and Tomcat
> 8.5.x are distinct versions, but since the major version number is the
> same, many have expectations that nothing serious is going to change.
> Of course, 8.5.x has *many* serious changes to it with respect to
> Tomcat 8.0.x. But this one seems to be tripping a lot of people up.
>

- 8.5 is already changing a number of things (since it's supposed to be 9,
so it's normal).
- the clients we're talking about are ancient.
- I only saw "a few" people affected, not "a lot".

It's better to avoid breaking things, but I don't see the benefit of
reverting it or bothering with an option.

Rémy

>
> Those who are filing bugs, etc. are quite adamant that the reason
> phrase is "required" for certain things. To be sure, the reason phrase
> will only be required by non-compliant clients, and so technically the
> client is at fault, here.
>
> I'm wondering what the wider community thinks about this change and
> whether or not we should consider reverting it for Tomcat 8.5.x.
>
> Again, please reply to the dev@ list, since that's where this
> discussion belongs. I just wanted to make sure I reached the widest
> audience possible to begin a discussion.
>
> Thanks,
> - -chris
>
> [1] http://svn.apache.org/viewvc?view=revision=r1702765
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYh6ZCAAoJEBzwKT+lPKRYnJgQAIe57jJw2iUk86I63NGsqPnY
> IKWjZoMuqd8vlczn8/FF/drWMV7ObYsrhsYmJATR5iVI+/xdEXB7n8cMO7B7+ryV
> Sxe1Tcmh/tBNJ83a8C+zSHWvnIELYRonHm9syApa7onPKcsoEe6MTrsdL1M+An9U
> 9IvXtH3BfYKAynze5pkNS6I+ILjgWvNSclJFHmDNHWmRPyqdob4OtMWkSSU3qRBX
> FfbEk9IMrEbIit6CH75dw9xfaUDDRudnw3MBkKaV8VOLUoykvSMK1w9GdufO4ohP
> Dw/+l6CkXl8xCSRcNwXrDdJcisT9gN6Ey7+g7zrgAcg62RP3ftrQMCzT2VDQV3b4
> IlZfTi+vEdsKKzGUdH+OLbN0+hiW0bnuxJmTG2zQSGwKsIh78aFdPKShv4u22XKB
> xfcKn9c6XGUHH88j0ZVSOLh2AmORCvuDfQNA3NJCOceRwQsV1OHAda65fFlkjyiz
> Q/yMMV8VlblGJRItN1nEwheIs9ru3MokRBhaXQ78ehSkRxbkIPawP6ZSiojmv/80
> aKx3/T413GOK4e18sK3XFHP4NowkR7VR/a1R5Py7L2kpzhMJcc4bstYuE9hugfiN
> BaECAT66qahCmP0xVoiFEB2A0+sD0wRKZ6K1gPCarPdLKh6cX4poRcMK4i0jgG2a
> cao/Frb1y8JDm8maw1Q8
> =oQCi
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Problems with tomcat 9 http/2 configuration

[Mark Thomas]

On 25/01/2017 22:11, Zigarelli, Michael wrote:
> Hi,
> 
> 
> I am unable to configure tomcat 9.0.0.M17 for http/2 support. My connector 
> for port 8443 has been uncommented and the necessary certificates were added 
> to it. I am receiving this error when I start my tomcat: Jan 25, 2017 4:28:21 
> PM org.apache.catalina.util.LifecycleBase handleSubClassException
> 
> SEVERE: Failed to initialize component 
> [Connector[org.apache.coyote.http11.Http11AprProtocol-8443]]
> 
> org.apache.catalina.LifecycleException: The configured protocol 
> [org.apache.coyote.http11.Http11AprProtocol] requires the APR/native library 
> which is not available

This means the APR/native Tomcat connector - not the standard APR library.

Mark


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

Problems with tomcat 9 http/2 configuration

[Zigarelli, Michael]

Hi,


I am unable to configure tomcat 9.0.0.M17 for http/2 support. My connector for 
port 8443 has been uncommented and the necessary certificates were added to it. 
I am receiving this error when I start my tomcat: Jan 25, 2017 4:28:21 PM 
org.apache.catalina.util.LifecycleBase handleSubClassException

SEVERE: Failed to initialize component 
[Connector[org.apache.coyote.http11.Http11AprProtocol-8443]]

org.apache.catalina.LifecycleException: The configured protocol 
[org.apache.coyote.http11.Http11AprProtocol] requires the APR/native library 
which is not available

at org.apache.catalina.connector.Connector.initInternal(Connector.java:924)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)

at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:530)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)

at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:875)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136)

at org.apache.catalina.startup.Catalina.load(Catalina.java:606)

at org.apache.catalina.startup.Catalina.load(Catalina.java:629)

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:497)

at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)

at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)

I am using eclipse to run my tomcat server. I have the APR library installed on 
my computer (Mac OS). I have added a VM argument in the run configurations of 
the server: -Djava.library.path="Path/to/lib" and the environmental variable 
LD_LIBRARY_PATH set to /usr/local/apr/lib. I am not sure what else to do here.

Re: How to configure tomcat to ignore large websocket messages

[Mark Thomas]

On 25/01/2017 21:12, Preston Price wrote:
> So what is the purpose of a Decoder.TextStream then if not to handle
> incomplete/partial messages?

To interface with other components that wanted to process the data in
that form.

Partial messages feeding an InputStream is doable, but you need to built
it yourself / find a framework (Atmosphere?) that has already done it
for you.

Mark

> 
> Cheers!
> 
> On Wed, Jan 25, 2017 at 2:07 PM, Mark Thomas  wrote:
> 
>> On 25/01/2017 20:53, Preston Price wrote:
>>> Is it possible to use a Decoder to handle partial websocket messages?
>>
>> No. Decoders only apply to whole messages.
>>
>> The closest you will get it is:
>> - remove the message size limit
>> - use a partial message handler that buffers up to a limit
>> - discard data once the buffer limit is exceeded
>> - ignore messages that exceed the buffer
>>
>> This makes the application vulnerable to a DoS via very large messages
>> unless there is some high limit than the buffer limit enforced.
>>
>> Mark
>>
>>>
>>> On Wed, Jan 25, 2017 at 1:29 PM, Mark Thomas  wrote:
>>>
 On 25/01/2017 20:25, Preston Price wrote:
> My environment:
> java: 1.8.0_102,
> tomcat: 8.0.39,
> os:Ubuntu 4.4.0-45-generic,
> websocket api: 1.1
>
> Currently in my application clients will (rarely) send a message that
> exceeds the default (8192 byte) limit for messages. This results in the
> socket being closed by the server with a 1009 code (too big). Can
>> tomcat
 be
> configured to ignore such large messages without closing the socket?

 No.

 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

Re: How to configure tomcat to ignore large websocket messages

[Preston Price]

So what is the purpose of a Decoder.TextStream then if not to handle
incomplete/partial messages?

Cheers!

On Wed, Jan 25, 2017 at 2:07 PM, Mark Thomas  wrote:

> On 25/01/2017 20:53, Preston Price wrote:
> > Is it possible to use a Decoder to handle partial websocket messages?
>
> No. Decoders only apply to whole messages.
>
> The closest you will get it is:
> - remove the message size limit
> - use a partial message handler that buffers up to a limit
> - discard data once the buffer limit is exceeded
> - ignore messages that exceed the buffer
>
> This makes the application vulnerable to a DoS via very large messages
> unless there is some high limit than the buffer limit enforced.
>
> Mark
>
> >
> > On Wed, Jan 25, 2017 at 1:29 PM, Mark Thomas  wrote:
> >
> >> On 25/01/2017 20:25, Preston Price wrote:
> >>> My environment:
> >>> java: 1.8.0_102,
> >>> tomcat: 8.0.39,
> >>> os:Ubuntu 4.4.0-45-generic,
> >>> websocket api: 1.1
> >>>
> >>> Currently in my application clients will (rarely) send a message that
> >>> exceeds the default (8192 byte) limit for messages. This results in the
> >>> socket being closed by the server with a 1009 code (too big). Can
> tomcat
> >> be
> >>> configured to ignore such large messages without closing the socket?
> >>
> >> No.
> >>
> >> 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
>
>


-- 
Preston M. Price
KidCheck
www.kidcheck.com
Facebook

 / Twitter 

-- 

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify KidCheck at 
supp...@kidcheck.com. Please note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of KidCheck. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete. Finally, the recipient should check this email 
and any attachments for the presence of viruses. KidCheck accepts no 
liability for any damage caused by any virus transmitted by this email.

Re: How to configure tomcat to ignore large websocket messages

[Mark Thomas]

On 25/01/2017 20:53, Preston Price wrote:
> Is it possible to use a Decoder to handle partial websocket messages?

No. Decoders only apply to whole messages.

The closest you will get it is:
- remove the message size limit
- use a partial message handler that buffers up to a limit
- discard data once the buffer limit is exceeded
- ignore messages that exceed the buffer

This makes the application vulnerable to a DoS via very large messages
unless there is some high limit than the buffer limit enforced.

Mark

> 
> On Wed, Jan 25, 2017 at 1:29 PM, Mark Thomas  wrote:
> 
>> On 25/01/2017 20:25, Preston Price wrote:
>>> My environment:
>>> java: 1.8.0_102,
>>> tomcat: 8.0.39,
>>> os:Ubuntu 4.4.0-45-generic,
>>> websocket api: 1.1
>>>
>>> Currently in my application clients will (rarely) send a message that
>>> exceeds the default (8192 byte) limit for messages. This results in the
>>> socket being closed by the server with a 1009 code (too big). Can tomcat
>> be
>>> configured to ignore such large messages without closing the socket?
>>
>> No.
>>
>> 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: How to configure tomcat to ignore large websocket messages

[Preston Price]

Is it possible to use a Decoder to handle partial websocket messages?

On Wed, Jan 25, 2017 at 1:29 PM, Mark Thomas  wrote:

> On 25/01/2017 20:25, Preston Price wrote:
> > My environment:
> > java: 1.8.0_102,
> > tomcat: 8.0.39,
> > os:Ubuntu 4.4.0-45-generic,
> > websocket api: 1.1
> >
> > Currently in my application clients will (rarely) send a message that
> > exceeds the default (8192 byte) limit for messages. This results in the
> > socket being closed by the server with a 1009 code (too big). Can tomcat
> be
> > configured to ignore such large messages without closing the socket?
>
> No.
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


-- 
Preston M. Price
KidCheck
www.kidcheck.com
Facebook

 / Twitter 

-- 

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify KidCheck at 
supp...@kidcheck.com. Please note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of KidCheck. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete. Finally, the recipient should check this email 
and any attachments for the presence of viruses. KidCheck accepts no 
liability for any damage caused by any virus transmitted by this email.

Re: How to configure tomcat to ignore large websocket messages

[Mark Thomas]

On 25/01/2017 20:25, Preston Price wrote:
> My environment:
> java: 1.8.0_102,
> tomcat: 8.0.39,
> os:Ubuntu 4.4.0-45-generic,
> websocket api: 1.1
> 
> Currently in my application clients will (rarely) send a message that
> exceeds the default (8192 byte) limit for messages. This results in the
> socket being closed by the server with a 1009 code (too big). Can tomcat be
> configured to ignore such large messages without closing the socket?

No.

Mark


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

How to configure tomcat to ignore large websocket messages

[Preston Price]

My environment:
java: 1.8.0_102,
tomcat: 8.0.39,
os:Ubuntu 4.4.0-45-generic,
websocket api: 1.1

Currently in my application clients will (rarely) send a message that
exceeds the default (8192 byte) limit for messages. This results in the
socket being closed by the server with a 1009 code (too big). Can tomcat be
configured to ignore such large messages without closing the socket?

Thanks

-- 
Preston M. Price
KidCheck
www.kidcheck.com
Facebook

 / Twitter 

-- 

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify KidCheck at 
supp...@kidcheck.com. Please note that any views or opinions presented in 
this email are solely those of the author and do not necessarily represent 
those of KidCheck. E-mail transmission cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete. Finally, the recipient should check this email 
and any attachments for the presence of viruses. KidCheck accepts no 
liability for any damage caused by any virus transmitted by this email.

Re: Apache/Tomcat vulnerability

[Jaaz Portal]

hi,
i just wanted to let you know that the we have migrated to WildFly
application server
and our server is up online 24/24h from three weeks.

Since this time it has never freezed so I suppose i was right saying
somebody found DoS exploit on tomcat.

Unfortunately I cannot help you in figure causes of this freeze that
happened one or two times a week.

best wishes,
artur

2016-12-01 2:46 GMT+01:00 Christopher Schultz 
:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jaaz,
>
> On 11/30/16 1:41 PM, Jaaz Portal wrote:
> > no it looks like dos, its dos
> >
> > i told you they dosed before bind server until we changed it to
> > other vendor, and later was scanning my host for apache
> > vulnerabilities
>
> Okay, let's just end this because obviously we've never going to get
> to the bottom of it.
>
> $ sudo iptables -A INPUT -s evil.host.pl -p tcp -m tcp -j DROP
>
> If they start coming at you from multiple IPs, use CIDR notation to
> block a whole subnet or whatever.
>
> Then when these "attacks" keep happening, you can block-out the whole
> world and you're application will never seize-up again.
>
> Review your configuration as Mark has suggested. If things are still
> not working, re-post with some actual data instead of just
> continuously posting "we are under attack, they dos bind, they dos
> mod_jk, they dos mod_proxy, what can we do?".
>
> Post. Logs.
>
> A single log line saying "server reached MaxRequestWorkers setting,
> consider raising the MaxRequestWorkers setting" is not an indication
> of any problem at all other than (lack of) accurate capacity planning.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJYP4D1AAoJEBzwKT+lPKRYM6AP/2H+NEy27YU92ccllLOcnBsA
> V8RW+lGUjI/nxYqODw2B1cjE8zhnvtPRokdWIkLu0rQA4mg7p/3iLcBvdkZXMAkc
> k16aZZk+wbtTgsqK/2ORQ+5lfn3nd4QTk2tzB/z/jJnb+7vp6/qa7ESpZLXi7p3U
> TniCZz0gVrykF7NVS1Ospvw/JcEuuFeo4gMnXIupYOqF9jlI1y0HydVreIOCwgq6
> fn/4UA9Ku6iGYuPE+k8AQvgbQ3ILaODVanUPTtLQstjfXpHUVGerakclUoxIOawH
> ZkzKledtsFzLByPFdI6/Y9+WXDAVtwCKVEFNWc2lHbogy6FC+5ozubRwC5MP8CO4
> vicaCl7X+hDwDfxAZEZp1pbGrAd0G7YGgzTSKz5r61t9opv8k5HjWqGFiB2MFob1
> jedbWvE40w/d54kuy+1MUAqjH5wM1Rw4hY7glALHiNVs1z5m83YFPYQhcbGdsi31
> PxAA5OTVU8hggsbVcq9P5qjYOIQlLH+b2//K2eZK/4QV6u9u0jMuhMq/eeEy93JW
> HPb0Uri/TK+LajrJ3fsMTKhWZDS4VkCB+kkJ3BedKDnq1yQMqckJW5WKx4wgaZHA
> lxnDbxPjq4nZLI3odsG1eiU7/7yl32tPTy3b038iTacihl5hMdIFZXM5VkoKvdi8
> AGidy4ZhsZ920ZAZQqJS
> =dqVz
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Character encoding issue in URL

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Justin,

On 1/25/17 12:25 AM, Justin Dang wrote:
> Hi, I have a clean install of an older version of Tomcat (8.0.24).
> I have noticed when a character is encoded in the URL, Tomcat fails
> to return the URL requested.  I've noted this same request
> performed in IIS works fine.
> 
> Apache Tomcat tests:
> 
> Works (No escape) –  http://localhost:8080/examples/delme/íj.pdf
> 
> Works (URL encoded) –
> http://localhost:8080/examples/delme/%C3%ADj.pdf
> 
> Failed (Char encoded) –
> http://localhost:8080/examples/delme/%EDj.pdf

You are mistaken. While you might think that %ED would map to U+00ED,
it does not. You need to use %C3%AD as you have done in your second
example, because the standard is UTF-8 and not UTF-16 or anything like
that.

%ED is not a valid character in UTF-8.

https://en.wikipedia.org/wiki/UTF-8#Description

> IIS tests:
> 
> Works (No escape)  –  http://localhost:8080/examples/delme/íj.pdf
> 
> Works (URL encoded) –
> http://localhost:8080/examples/delme/%C3%ADj.pdf
> 
> Works (Char encoded) –
> http://localhost:8080/examples/delme/%EDj.pdf
> 
> 
> I've reviewed this wiki page:
> 
> 
> https://wiki.apache.org/tomcat/FAQ/CharacterEncoding
> 
> 
> And it seems to imply that I shouldn't have to do anything, and the
> URL request should return properly.
> 
> 
> So my question is, what do I need to configure in Apache Tomcat to
> handle the character encoding request like IIS does?

Only by violating UTF-8.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYiNiJAAoJEBzwKT+lPKRY0I4P/2B84M/wkoomYdL3T2mgG7Pg
MjijT7cRrAnX/OhJsT1vILKFVeW8nB6O6IV2NDUx4CtqcVg/ce4cYPmoy0qADMyu
qHmwybGMauoIM6uamA1jxDiNWGElW36Wa6y8ESySFG0qzsK8o++XJMCINlS2hQJ9
g7dBcfVLXQc9PTYIGbrAQQ/oSVViRRgfsW5TgH0YlVfie1iSASRm9lcYLHliDGH9
S3NMPdmaRE+lwkrKJ1X6r+Kxz95e5hxQWQPXc4xGGcmZEC8PWcnQRiCob/TCqJUh
obKNrLEC/GvJ8gu7eCEFMDd6usjUIxJVjhGJDPo0vxVcLIJ9dte2kq714u12w7kl
49AMoyz+3Co5W5PheeqQnIoJhA5sqJRP3KxuxcfTJE7TyKn+SE2moC0twDKpur5W
exu5ps2wdaBmIBE3S5aXxGYpFmlm5dvdcM1lQjoiIdg5JdKZLacxP7DBCaVT8UC9
4/Siu1iDBz0KnEwCoBhFjlr8qVoSgCfRV6VEHjhr9z+yEG60cnniVk2diYdpcpia
W/iPEe7nFhzBjNelqh1IL9XlogTc4IIoL0T88ti5EYks/pKgr4Ilsh08IkJhtHk6
vH3jCmdbR3c3Gb002lOMk9oBYyvOSxnwUr34n7KXcEYitJd8a8YNm+tNsKQ14ZLS
1z8g/1zJZSrGZdX6n8g9
=4ASz
-END PGP SIGNATURE-

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

Re: embedded tomcat (8.0.39) shared jars

[Tom Eugelink]

I've examined the issue more closely. The class (interface) is loaded twice, 
once by WebappClassLoader and once by  Launcher$AppClassLoader, both from 
StandardContext.listenerStart() line: 4853

The WebappClassLoader one is reached via regular method calls, the other 
through reflection:

MapperRegistry.getMapper(Class, SqlSession) line: 40
Configuration.getMapper(Class, SqlSession) line: 639
SqlSessionManager.getMapper(Class) line: 215
MyBatisDbSessionManager.getMapper(Class) line: 84
ProcessTasksService(BasisRestService).initializeAfterBootstrap() line: 57
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) 
line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43
Method.invoke(Object, Object...) line: 498
Delegate.invoke(Object, Object[]) line: 88
BootstrapCompleteSignal(SynchronousSignal).callHandler(SignalHandler, T) 
line: 22
BootstrapCompleteSignal(Signal).invokeSignalHandlers(T) line: 109
BootstrapCompleteSignal(Signal).raise(T) line: 131
BootstrapCompleteSignal(Signal).raise() line: 93
AnubIsContainer.bootstrap(String) line: 230
AnubIsContainer.bootstrap() line: 156
MySystemPropertiesHelper.contextInitialized(ServletContextEvent) line: 14
StandardContext.listenerStart() line: 4853
StandardContext.startInternal() line: 5314
StandardContext(LifecycleBase).start() line: 145
ContainerBase$StartChild.call() line: 1408
ContainerBase$StartChild.call() line: 1398
FutureTask.run() line: 266
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142
ThreadPoolExecutor$Worker.run() line: 617
Thread.run() line: 745

Does the reflection cause the other classloader to be used?

Tom


On 21-1-2017 09:43, Tom Eugelink wrote:

I'm very close at getting the embedded Tomcat running from an Eclipse Maven 
project; the (hopefully final) issue I'm now facing is the fact that a class is 
being loaded by the WebappClassloader and in another execution path via the 
launcher classloader, which makes them two different classes and things go awry.

Tomcat of course is being started by Eclipse with a full classpath, and I 
'forward' that classpath to the webapp. If I do not do that, the webapp won't 
find anything that is on that startup classpath, so apparently Tomcat's 
classloading setup completely ignores the initial classpath and replaces it 
with its own structure. Ok, but somehow they do get mixed up, otherwise I would 
not run into the situation described above. So I was thinking that I could try 
and figure out why one class is being loaded by the launcher, but I foresee a 
long and windy path, with a lot of different situations where this loading goes 
wrong. So instead of trying to solve the conflict at webapp level, I could move 
in another direction: in normal (non embedded) Tomcat installations you are 
allowed to put shared jars in Tomcat's lib folder. These are then accessible by 
all webapps.

Is it possible to have embedded Tomcat make its classpath available to the 
webapps, or configure the classes-directories and jars resources at Tomcat 
level?

Tom

-
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: Mutual certificate authentication between Tomcat and MS IIS

[Macca, Diego]

Thanks, we will try your suggestions. In the meantime we logged a request in 
Microsoft.
I'll keep you posted.


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 24 January 2017 22:46
To: Tomcat Users List
Subject: Re: Mutual certificate authentication between Tomcat and MS IIS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Diago,

On 1/24/17 4:41 PM, Christopher Schultz wrote:
> Diago,
>
> On 1/24/17 11:40 AM, Macca, Diego wrote:
>> On 1/24/17 8:24 AM, Macca, Diego wrote:
 Has somebody of you ever tried to configure certificate mutual
 authentication between a MS IIS webserver and a Tomcat instance?
>
>>> You want IIS to present a client certificate to Tomcat? Tomcat
>>> shouldn't have a problem with that.
>
>> Yes, that's what I need. Tomcat does not have any problem and it
>> works well with Apache. It seems that IIS is not able to present the
>> certificate when I configure it as reverse proxy (so when it should
>> act as a client).
>
 Does somebody know if this is even possible in IIS ?
>
>>> You'd have to configure IIS's HTTP proxy to use a client
>>> certificate.
>
>> Do you know how to configure it ? I mean, IIS does the reverse proxy
>> things but I need it also to send the present to Tomcat.
>
> I don't know at all how to configure it, unfortunately.
>
> Do you need to have IIS *forward* the actual client's certificate to
> Tomcat, or do you want to use a static client cert just from IIS? If
> you want to forward the cert, you might find this useful:
> https://blogs.msdn.microsoft.com/asiatech/2014/01/27/configuring-arr-w
it
>
>
h-client-certificate/

If you want to install a single certificate into the reverse-proxy, perhaps 
this can help:
https://blogs.msdn.microsoft.com/benjaminperkins/2014/06/02/configure-ap
plication-request-routing-arr-with-client-certificates/

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYh8sEAAoJEBzwKT+lPKRYV2sQAJ5dSq7UkrBeaiipMS9VCuPm
1925yNm22ewsPnwNAZ5Vo9koRXbYAg/AVMAHgf1Ge8umrTYAByfno2gtTcuBtJEb
DBHlm+9uPI+UZdbTs+GsdfW11nCYFc2DFy0cwDewO+N57h26Ji8MLtbd0SwVtYWG
LxwA3chdX6pFc1Q1SlEF0XUT89TNZHL1OJUk5QgY4IxwQHOjqKq+dBv5SmgrEeSp
rGkkzL+hL6AGjt4JmT1z+lnSiCZryO1Sn8gEuD8b+bob8t9S4Gmsg2/clVYNdvwL
nfvpQYTkuZNawaUQCLmMfGoiLf3c6e3expTB09mtOKZA43c6hLXG9lKaI1/A/kOy
Z34S3Uriy+NZaFjyClrrY7AvjjgENS4hQoElDdXXk3PFqOQRz5mSUKQAi1ksM9aK
wyC8EYLaME2nO18KpIDcCrJCXTdwPBZCRWqu8QR26Vz0cLlqxd/B7WZLaiJgjzlN
1DZkAgVYdb0UFmbg/d012CVRlsMlMcs6tPaVoh8I8cB80wl/A6s6kQ6xCpGBDmto
yfA4rl7STfou/868kx5NZ2/msJvs2DD909RNBbZ625aYTtLash82ttwLX42uTiAp
JFJr/wnhGSCibfxmDjVEOoxMIbHTGm1PHF2yvi55aDTF9IyC32JSmlvncI5tedrI
l+TLRr57yPiAJ6tOh+5R
=ZSq/
-END PGP SIGNATURE-

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

Any e-mail message from the European Central Bank (ECB) is sent in good faith, 
but shall neither be binding nor construed as constituting a commitment by the 
ECB except where provided for in a written agreement. This e-mail is intended 
only for the use of the recipient(s) named above. Any unauthorised disclosure, 
use or dissemination, either in whole or in part, is prohibited. If you have 
received this e-mail in error, please notify the sender immediately via e-mail 
and delete this e-mail from your system. The ECB processes personal data in 
line with Regulation (EC) No 45/2001 and Decision ECB/2007/1. For any further 
information you can consult the Data Protection Disclaimer on the ECB webpage. 
In case of queries, please contact the ECB Data Protection Officer 
(d...@ecb.europa.eu). You may also contact the European Data Protection 
Supervisor.

RE: Separate and Redirect Tomcat Embedded 8.5.6 Log

[Costin Giorgian Papuc]

Hi Chris,

Thanks for your answer.
But this seems to not change anything.
It's there a way to get an InputStream() for each context? Or set a logger or 
something?
From what I saw I can only getLogger() but I cant add a FileHandler to this.

Costin

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, January 24, 2017 12:30 AM
To: Tomcat Users List 
Subject: Re: Separate and Redirect Tomcat Embedded 8.5.6 Log

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Costin,

On 1/20/17 5:39 AM, Costin Giorgian Papuc wrote:
> I have an app that can take a war file and deploy it with embedded
> tomcat .5.6. So, for each uploaded war file I do the following
>
> Tomcat tomcat = new Tomcat(); tomcat.setPort(port); File catalinaHome
> = new File(TOMCAT_DIR + port); catalinaHome.mkdirs(); File webapp =
> new File(TOMCAT_DIR + port + "\\webapps");
> webapp.mkdir(); tomcat.setBaseDir(catalinaHome.getAbsolutePath());
>
> try { File war = new File("myapp.war"); //the given war file
> StandardContext context = (StandardContext) tomcat.addWebapp("/myapp",
> war.getAbsolutePath()); context.setAntiResourceLocking(true);
> tomcat.start(); } catch (Exception e) { e.printStackTrace(); }
>
> I don't have any idea how can I redirect the output. I read that
> tomcat embedded log to System.out, and I was able to redirect to file
> with: PrintStream out = new PrintStream(new
> FileOutputStream("output.txt")); System.setOut(out); but redirect all
> output, and I want something that log to a different file for each
> tomcat instance that I run. Any solution that I found so far don't
> resolve my problem. So, how can I separate output for each tomcat
> instance?

Try setting swallowOutput="true" [1] for each of the contexts you deploy .

- -chris

[1] https://tomcat.apache.org/tomcat-8.0-doc/config/context.html
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJYhoQAAAoJEBzwKT+lPKRYp+QP/2CxRxua+yW1riHubZilKoy/
R3cDpMQuN7UIOIsgr5ImO8ST7/vAdAkvXMB1bastJ5Btbtc6+K5hdv6HGQb86fT7
aKsut81O3VzBuwBiLIkhyjEDxAT3WU3WVS7BY/hnoDvVeRRS98Kat0tuzJZEPT/e
K8NFnwU7x7jCgI+ruf888O0ukhib1t/9DXjuY/fW9h0moJJDttbo8D6//Dh9H2zd
YvO6n7yIIIAs5FHmJIH4RwP7xOqaMDStGZBxi1cqkaZOcp4ZeCdEi0kekQwhCSK+
bPZ1zNp6fdOYfVIWhAqic44CUSDZmdWMNp3KZ5Ei2/VFllpE+lDYaTvS9TfyEP+n
XxkW03zEFm9QHVIo/35Jbp3mj7YnuJpjvnLOCWrWEvxas+omwJZGbTKlQRNHVTi/
Ez2uKUcJoTfvf9UXqdFDDSncnL7J9YcN7mp1M5tqCxiVkokAZWQs272WDpghNMdl
4Y22rjJJqnRnlr1UpXz/+RHzInl2Jt8yEzC4Ta8zBv1urSSucYQwbTHkNhLerZqT
0Kq4O+OaZEU0sbrG+iHPKCccoIr3i/vpN306F9yCSdSA1aLlWeJqwwL0184JzEXm
pgS1FMDLCLHeRLl6eVhMWegAful13ABQ3DCVayLmR2/a3S5kq484V2OhLsgeAKxH
8iim5GKxss+o/JHB6W89
=qtf5
-END PGP SIGNATURE-

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


The information in this email is confidential and may be legally privileged. It 
is intended solely for the addressee. Any opinions expressed are mine and do 
not necessarily represent the opinions of the Company. Emails are susceptible 
to interference. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on 
it, is strictly prohibited and may be unlawful. If you have received this 
message in error, do not open any attachments but please notify the Endava 
Service Desk on (+44 (0)870 423 0187), and delete this message from your 
system. The sender accepts no responsibility for information, errors or 
omissions in this email, or for its use or misuse, or for any act committed or 
omitted in connection with this communication. If in doubt, please verify the 
authenticity of the contents with the sender. Please rely on your own virus 
checkers as no responsibility is taken by the sender for any damage rising out 
of any bug or virus infection.

Endava Limited is a company registered in England under company number 5722669 
whose registered office is at 125 Old Broad Street, London, EC2N 1AR, United 
Kingdom. Endava Limited is the Endava group holding company and does not 
provide any services to clients. Each of Endava Limited and its subsidiaries is 
a separate legal entity and has no liability for another such entity's acts or 
omissions.

[ANN] Apache Tomcat 8.0.41 available

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.0.41.

Please note that Tomcat 8.x users should normally be using 8.5.x
releases in preference to 8.0.x releases.

Apache Tomcat 8.0 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language and Java
WebSocket technologies.

Apache Tomcat 8.0.41 includes fixes for issues identified in 8.0.39 as
well as other enhancements and changes. The notable changes since 8.0.39
include:


- Improve handling of varargs in UEL expressions

- Ensure that the endpoint is able to unlock the acceptor thread during
  shutdown if the endpoint is configured to listen to any local address of
  a specific type such as 0.0.0.0 or ::


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.0-doc/changelog.html

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

Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

[ANN] Apache Tomcat 7.0.75 released

[Violeta Georgieva]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 7.0.75.

Apache Tomcat is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Expression Language and Java
WebSocket technologies.

This release contains a number of bug fixes and improvements compared to
version 7.0.73. The notable changes since 7.0.73 include:


- Add support for varargs in UEL expressions

- Ensure that the endpoint is able to unlock the acceptor thread during
  shutdown if the endpoint is configured to listen to any local address of
  a specific type such as 0.0.0.0 or ::


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html

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

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

Enjoy

The Apache Tomcat team

AW: https redirect failed for POST request when behind a load balancer

[Kreuser, Peter]

Bin,

> Peter:
> Here is what I got when using curl on a client.
> curl -I http://lb-api:8080/urls?param1=something\=123
> HTTP/1.0 302 Found
> Location: https://lb-api:8443/ urls?param1=something\=123
> Server: BigIP
> Connection: Keep-Alive
> Content-Length: 0
> 

So it is working as designed in the RFC...

https://en.wikipedia.org/wiki/HTTP_302 -> 302 leads to a resend with GET.

If your client would speak HTTP/1.1, a 307 response code could be interpreted 
as preserving the request type as originally sent. It may be feasible to send 
this RC in a BigIP iRule for this specific URL. But it is still depending on 
the client implementation. And I have not seen this in the wild.

Now: how does the client get to the POST with http? If your app runs in a 
regular browser and uses relative URLs, upgrade the first request to https 
(probably a GET), then after that all links, forms will be on https.

Best regards

Peter



> Our engineer who has access to the load balancer is off today, will get some 
> log info on the load balancer side about the redirect.
> 
> Thank you,
> 
> Bin
> 
> -Original Message-
> From: Kreuser, Peter [mailto:pkreu...@airplus.com] 
> Sent: Tuesday, January 24, 2017 7:06 AM
> To: Tomcat Users List 
> Subject: AW: https redirect failed for POST request when behind a load 
> balancer
> 
> These are the responses to the redirected calls. But the redirect to https is 
> happening before...
> 
> 
> 
> Something like:
> 
> 
> 
> curl -I 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mysite.com=DwIGaQ=uilaK90D4TOVoH58JNXRgQ=T34XNMuHs99f3YkStEdBgUp9XTcpTRir8U9GVk2H5hQ=s9vxUp8T2qmtXcpTf24_22u9yokdaI0KB86CHPf6Eww=h-Vox3nBr8QIbljS45du0NmHAfIlQh6G_lmOdT4wuek=
>  
> 
> HTTP/1.0 301 Moved Permanently
> 
> Location: https:// www.mysite.com 
> 
> Server: Apache
> 
> Connection: Keep-Alive
> 
> Content-Length: 0
> 
> 
> 
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>  
>