I've found that certain applications will no longer invalidate
sessions after upgrading from 7.0.53 to 7.0.54.
It seems to require clustering to be set up in Tomcat. If it's not set
up, session invalidation works fine.
So far, I can only trigger it in a webapp that uses Tapestry Spring Security.
I have found that under JRE 6 (haven't tested 7 for performance yet,
only functionality) that the server jvm gives me much better performance
for Tomcat than the client JVM does.
However, I can only find a 64-bit server JVM for Java 7, while in Java
6, there was both a 32-bit and 64-bit server
Hi David,
> -Original Message-
> From: David kerber [mailto:dcker...@verizon.net]
> Sent: Thursday, May 29, 2014 3:35 PM
>
> I have found that under JRE 6 (haven't tested 7 for performance yet,
> only functionality) that the server jvm gives me much better performance
> for Tomcat than th
On Tue, May 27, 2014 at 2:21 PM, Mark Thomas wrote:
> On 27/05/2014 17:31, John Smith wrote:
> > Tomcat 7.0.42, RHEL6, JDK1.7.0_25, Standalone TC configuration. IPTABLES
> > route port 80 to 8080
> >
> > I've got a subdirectory like 'www.mysite.com/admin' that I want to put
> > under FORM based
Thanks, Konstantin, that was what I needed. I knew but had forgotten
about the JDK having the server JRE.
Dave
On 5/29/2014 9:58 AM, Konstantin Preißer wrote:
Hi David,
-Original Message-
From: David kerber [mailto:dcker...@verizon.net]
Sent: Thursday, May 29, 2014 3:35 PM
I have
>
>
>
>> 2. With the SSL connector enabled, https://* is globally respected on the
>> entire webapp. Do I need to manually check the URL/protocol to deny or
>> redirect https to http outside of '/admin'? Is there any built in TC
>> mechanism or suggested best practice to handle this? or should I no
2014-05-29 11:58 GMT+04:00 David Rees :
> I've found that certain applications will no longer invalidate
> sessions after upgrading from 7.0.53 to 7.0.54.
>
> It seems to require clustering to be set up in Tomcat. If it's not set
> up, session invalidation works fine.
>
> So far, I can only trigger
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
On 5/27/14, 2:41 PM, Christopher Schultz wrote:
> All,
>
> On 5/27/14, 8:46 AM, Mark Thomas wrote:
>> CVE-2014-0095 Denial of Service
>
>> Severity: Important
>
>> Vendor: The Apache Software Foundation
>
>> Versions Affected: - Apache Tomc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 5/28/14, 8:12 AM, Mark Thomas wrote:
> On 28/05/2014 13:06, David kerber wrote:
>> Right now I'm running TC 7.0.22 on Windows Server 2008 R2, as
>> windows services. Not using APR.
>>
>> To upgrade to the latest version, I should be able
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Dino,
On 5/28/14, 5:49 AM, Dino Ciuffetti wrote:
> Hi there. My name is Dino Ciuffetti, I'm a linux sysadmin and I'm
> new to this list.
>
> I have a sporadic problem with mod_jk (tomcat connectors), I hope
> someone can help me on this.
>
> I hav
Hey guys,
I found this on the web, and it really alarms me because my web app which
is in development depends on Comet technology to work.
http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_sends_data_to_a_wrong_user.html
Before I start digging into the tomcat7 source code, can anyone verify or
oh yea, im on tomcat 7 btw
On Thu, May 29, 2014 at 2:13 PM, Elias Kopsiaftis wrote:
> Hey guys,
>
> I found this on the web, and it really alarms me because my web app which
> is in development depends on Comet technology to work.
>
>
> http://bighow.net/4294974-Comet_under_Tomcat_6_0_33_sends_
On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote:
oh yea, im on tomcat 7 btw
Then why are you asking about a problem in a very old version of Tomcat 6?
On Thu, May 29, 2014 at 2:13 PM, Elias Kopsiaftis wrote:
Hey guys,
I found this on the web, and it really alarms me because my web app whi
To make sure it doesnt exist in Tomcat7. Thats why. Ive never looked into
the tomcat source code and theres no point for my current project unless
this bug still exists. Just trying to save myself the work. Also, I couldnt
find a page of known tomcat7 comet issues. If such a page existed it would
b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 5/29/14, 2:45 PM, David kerber wrote:
> On 5/29/2014 2:21 PM, Elias Kopsiaftis wrote:
>> oh yea, im on tomcat 7 btw
>
> Then why are you asking about a problem in a very old version of
> Tomcat 6?
+1
Also, that web site looks like a scr
On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko
wrote:
> 2014-05-29 11:58 GMT+04:00 David Rees :
>> I've found that certain applications will no longer invalidate
>> sessions after upgrading from 7.0.53 to 7.0.54.
>>
>> It seems to require clustering to be set up in Tomcat. If it's not set
>>
ok thanks guys, I just got freaked out when I saw that post.
On Thu, May 29, 2014 at 3:10 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> David,
>
> On 5/29/14, 2:45 PM, David kerber wrote:
> > On 5/29/2014 2:21 PM, Elias Kop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Elias,
On 5/29/14, 3:12 PM, Elias Kopsiaftis wrote:
> ok thanks guys, I just got freaked out when I saw that post.
There are other things that might freak you out. Read the security
statements for Tomcat 7, for instance, and decide if you are at th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Elias,
On 5/29/14, 3:08 PM, Elias Kopsiaftis wrote:
> To make sure it doesnt exist in Tomcat7. Thats why. Ive never
> looked into the tomcat source code and theres no point for my
> current project unless this bug still exists. Just trying to save
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
David,
On 5/29/14, 3:12 PM, David Rees wrote:
> On Thu, May 29, 2014 at 8:51 AM, Konstantin Kolinko
> wrote:
>> 2014-05-29 11:58 GMT+04:00 David Rees :
>>> I've found that certain applications will no longer invalidate
>>> sessions after upgradin
On Thu, May 29, 2014 at 12:16 PM, Christopher Schultz
wrote:
> Do you mean that you have a web application that does this:
>
> session.invalidate();
> session = request.getSession(true);
>
> ... and the old session is in fact not invalidated?
Yes. Specifics to make this happen seem to be:
TC
I am having random errors, but we are still looking into them because right
now we think they are probably from our end. The current one is that the
connection from the client to the comet servlet will randomly repeatedly
receive "NULL". Still looking into this to see what the server is doing
On
On Thu, May 29, 2014 at 12:39 PM, David Rees wrote:
>
> Yes. Specifics to make this happen seem to be:
>
> TC 7.0.54 in a cluster, Tapestry 5.2.6 + Tapestry Spring Security.
OK, I was wrong, no Tapestry or Spring Security is required, just a
couple JSPs are required to reproduce. Key is that clus
On Thu, May 29, 2014 at 6:16 PM, David Rees wrote:
> I'll open a ticket with these details, too.
https://issues.apache.org/bugzilla/show_bug.cgi?id=56578
-Dave
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For a
24 matches
Mail list logo
