Hi
Thanks for replying for on my question.
Please find the details below, you had requested. sorry for troubling you
much , i ma hereby providing the details of server.xml below.
?xml version='1.0' encoding='utf-8'?
!--
Licensed to the Apache Software Foundation (ASF) under one or more
You seem to have missed the Please remove all of the commented parts.. part
of the request.
rakesh k wrote:
Hi
Thanks for replying for on my question.
Please find the details below, you had requested. sorry for troubling you
much , i ma hereby providing the details of server.xml below.
Hi Andre
Sorry for this, I had pasted the entire xml file.. I am hereby providing the
server.xml with removing the commented parts.
?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN
Listener className=org.apache.catalina.core.AprLifecycleListener
SSLEngine=on /
How do you accomplish that? By doing this SSO sniff-and-kill-session
thing? It seems more straightforward to expire a particular webapp's
session explicitly and let the SSO expire along with it.
Doesn't that mean you'll have to re-run the same query just to expire
the sessions in the other
Chris,
As mentioned in an earlier post, our clients are not web browsers and do not
support cookies. Session management is handled via an internally generated
session id, and I am attempting to adapt an existing infrastructure to load
balancing with session stickiness. The recommendations I
Greetings,
A recent update to Tomcat (7.0.20) notes the vulnerability affects Linux. I
wanted to ask if that is Linux and only Linux or does it include other
Unix-like system(or even Unix proper)?
Thanks!
Randal
On 16/08/2011 16:56, Randal Bankman wrote:
Greetings,
A recent update to Tomcat (7.0.20) notes the vulnerability affects Linux. I
wanted to ask if that is Linux and only Linux or does it include other
Unix-like system(or even Unix proper)?
It applies to any OS that uses jsvc, which is
On 08/16/2011 05:59 PM, Mark Thomas wrote:
On 16/08/2011 16:56, Randal Bankman wrote:
Greetings,
A recent update to Tomcat (7.0.20) notes the vulnerability affects Linux. I
wanted to ask if that is Linux and only Linux or does it include other
Unix-like system(or even Unix proper)?
It
On 16/08/2011 17:01, Mladen Turk wrote:
On 08/16/2011 05:59 PM, Mark Thomas wrote:
On 16/08/2011 16:56, Randal Bankman wrote:
Greetings,
A recent update to Tomcat (7.0.20) notes the vulnerability affects
Linux. I wanted to ask if that is Linux and only Linux or does it
include other
From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, August 16, 2011 12:03 PM
Subject: Re: CVE-2011-2729
On 16/08/2011 17:01, Mladen Turk wrote:
On 08/16/2011 05:59 PM, Mark Thomas wrote:
On 16/08/2011 16:56, Randal
Hi - I'm trying to migrate my IBI Web Focus application to new servers with an
upgraded OS and the web focus application is not receiving the sitminder HTTP
Header request through the ISAPI filter through to Tomcat.
Our server is setup with the following:
* Windows 2003
* IIS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chema,
On 8/16/2011 4:33 AM, Chema wrote:
How do you accomplish that? By doing this SSO
sniff-and-kill-session thing? It seems more straightforward to
expire a particular webapp's session explicitly and let the SSO
expire along with it. Doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Karl,
On 8/16/2011 7:00 AM, Lataxes, Karl wrote:
As mentioned in an earlier post, our clients are not web browsers
and do not support cookies. Session management is handled via an
internally generated session id, and I am attempting to adapt an
Hi,
CLN 1126273
http://svn.apache.org/viewvc?view=revisionrevision=1126273
Seems to have disabled the automatic addition of the cache-control and pragma
response headers on secure constrained pages.
The initial revision of this file(at least the oldest copy I could find) had
this check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael,
On 8/16/2011 4:42 PM, Zampani, Michael wrote:
I don't understand why it was ever present, though. Does anybody
know why you wouldn't want these headers on secure requests?
The svn comment says ...to reduce the likelihood of issues when
On 08/16/2011 03:57 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael,
On 8/16/2011 4:42 PM, Zampani, Michael wrote:
I don't understand why it was ever present, though. Does anybody
know why you wouldn't want these headers on secure requests?
The svn
It was my understanding that the fix for IE was just the securePagesWithPragma
change, which changes cache-control:no-cache to cache-control:private by
default.
According to the bug report, this should fix IE downloads even for secure
requests.
The problem is, this entire block is now ignored
17 matches
Mail list logo
