On 24/09/12 17:52, Mark Thomas wrote:
On 24/09/2012 11:41, Brian Burch wrote:
I draw the following conclusions:
1. A client that can accept a Set-Cookie for JSESSIONID will be able to
maintain a persistent session (is that incorrectly overloading a
reserved word?), no matter whether the
On 24/09/12 19:50, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 9/23/12 5:46 AM, Brian Burch wrote:
However, in the case where the client is not using cookies (my
test disables them for its Context), there does not appear to be a
way for the server to
On 23/09/12 11:10, Mark Thomas wrote:
Thanks for looking at my questions, Mark. I hoped you would find time,
because you fixed the original bug quite recently and would still
remember the rather convoluted logic for FORM authentication.
On 23/09/2012 10:46, Brian Burch wrote:
With
On 24/09/2012 11:41, Brian Burch wrote:
I draw the following conclusions:
1. A client that can accept a Set-Cookie for JSESSIONID will be able to
maintain a persistent session (is that incorrectly overloading a
reserved word?), no matter whether the session ID is changed once, many
times,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 9/23/12 5:46 AM, Brian Burch wrote:
However, in the case where the client is not using cookies (my
test disables them for its Context), there does not appear to be a
way for the server to communicate the new jsessionid value to the
With reference to:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53584
I reproduced the problem using the sample war on a back-level svn
version of the trunk, then confirmed the problem was fixed on a later level.
I have been developing a new unit test case in
On 23/09/2012 10:46, Brian Burch wrote:
With reference to:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53584
I reproduced the problem using the sample war on a back-level svn
version of the trunk, then confirmed the problem was fixed on a later
level.
I have been developing a
