-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 9/17/2010 7:00 AM, Brian McBride wrote:
> My interpretation is still that 2109 defines the
> behaviour of Set-Cookie and 2965 that of Set-Cookie2 and that the intent
> was that Set-Cookie2 should obsolete Set-Cookie, i.e. 2109 still defines
On 16/09/2010 15:50, André Warnier wrote:
[...]
RFC 2965 does not say that it overrides the older RFC 2109.
It does, at the end of the Abstract :
This document reflects implementation experience with RFC 2109 and
obsoletes it.
I missed that. My interpretation is still that 2109 defines
On 16/09/2010 14:46, Joseph Morgan wrote:
> Mark... on that thought, Java 1.5+ has the java.net.CookieHandler class... is
> there a way to insert a CookieHandler into Tomcat???
Not without writing some custom code to replace some of Tomcat's internals.
Mark
-
Brian McBride wrote:
On 14/09/2010 23:17, André Warnier wrote:
[...]
Personal interpretation : if the browser receives a cookie marked
"secure", it should only send it back with requests happening over an
HTTPS connection.
(No matter if it was received over HTTP or HTTPS).
I'm using httpunit
: HtttServletRequest.getSession()
On 16/09/2010 13:49, Brian McBride wrote:
> Is there a way to persuade Tomcat to use Set-Cookie2 headers?
Not though the Servlet API. The servlet spec references v0 and v1
cookies but not the v2 spec.
Given the IE doesn't even fully implement the v1 cookie spec, I would
On 16/09/2010 13:49, Brian McBride wrote:
> Is there a way to persuade Tomcat to use Set-Cookie2 headers?
Not though the Servlet API. The servlet spec references v0 and v1
cookies but not the v2 spec.
Given the IE doesn't even fully implement the v1 cookie spec, I would
estimate the chances of it
On 14/09/2010 23:17, André Warnier wrote:
[...]
Personal interpretation : if the browser receives a cookie marked
"secure", it should only send it back with requests happening over an
HTTPS connection.
(No matter if it was received over HTTP or HTTPS).
I'm using httpunit for testing. I obser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
Thanks for further investigation. Comments, as always, are below.
On 9/14/2010 6:17 PM, André Warnier wrote:
> 3.3.3 Cookie Management If a user agent receives a Set-Cookie2
>response header whose NAME is the same as that of a cookie it
Mark Thomas wrote:
On 14/09/2010 15:16, Christopher Schultz wrote:
I'm in the middle of some major re-factoring so I don;t have time to
actually test this...
0. [Browser has two JSESSIONID cookies: one secure=true and one
secure=false]
This I doubt. When testing load-balancing on a single ma
On 14/09/2010 15:16, Christopher Schultz wrote:
I'm in the middle of some major re-factoring so I don;t have time to
actually test this...
> 0. [Browser has two JSESSIONID cookies: one secure=true and one
> secure=false]
This I doubt. When testing load-balancing on a single machine, I have
seen
Hi Christopher,
On 14/09/2010 16:02, Christopher Schultz wrote:
[...]
I'm not sure what you're asking. "The session" refers to an HttpSession
object, which should be obvious from the spec and the API itself. "The
request" should also be obvious, since we're talking about HTTP and a
HttpServletR
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 9/14/2010 9:51 AM, Brian McBride wrote:
>https request: get session returns ?
Heh. I should have read your question before I posted my own.
> i.e. will the newly created session B replace session A, or will A
> continue to be returned
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark,
On 9/14/2010 7:55 AM, Mark Thomas wrote:
> On 14/09/2010 10:40, Brian McBride wrote:
>> The javadoc states this call returns the "session associated with the
>> request". I'm trying to figure out what "the session associated with
>> the reques
Hi Mark,
Thanks for this. I didn't quite fully grock your reply. Given:
https request: get session returns session A.
https request: get session returns session A.
http request: get session (no create) returns null
http request: get session(create) returns session B != A.
ht
On 14/09/2010 10:40, Brian McBride wrote:
> The javadoc states this call returns the "session associated with the
> request". I'm trying to figure out what "the session associated with
> the request" actually means.
>
> Specifically, if I have the same client sending https and http requests
> in
The javadoc states this call returns the "session associated with the
request". I'm trying to figure out what "the session associated with
the request" actually means.
Specifically, if I have the same client sending https and http requests
intermixed in time, will there be two sessions objec
16 matches
Mail list logo
