> What I suggest we do instead (for both 3.2 and 4.0, by the way) is to
treat the *first*
> JSESSIONID occurrence that is submitted as the one that is relevant for
this web
> application. This is based on a requirement in the cookie spec (RFC 2109)
that the browsers
> actually seem to be obeying:
>
> "If multiple cookies satisfy the criteria above, they are
> ordered in the Cookie header such that those with more
> specific Path attributes precede those with less specific."
>
For what its worth, a lot of browsers don't seem to do this correctly. One
of the developers that I work with was telling me that versions of Netscape
4.7 don't do this correctly, and I've had experiences with the Phone.com WAP
browser that indicate that the browser is *very* broken in how and when it
handles, replaces, deletes, and expires cookies.
For instance, the Phone.com 4.0 WAP browser emulator doesn't do cookie
replacement, which means that it will pass up multiple JSESSIONID cookies
for the same path attribute. This violates section 4.3.3 of RFC 2109, but
the Phone.com browser is in every WAP phone in north america, which makes it
a de facto standard:
"If a user agent receives a Set-Cookie response header whose NAME is the
same as a pre-existing cookie, and whose Domain and Path attribute values
exactly (string) match those of a pre-existing cookie, the new cookie
supersedes the old."
I would recommend testing cookie behavior with a large number of browsers
before committing to any strategy for handling cookies.
-Colin
--
Colin Evans
Bitmo, Inc. (http://www.bitmo.com)
(415)920.7225 / [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
