HttpCookie, InMemoryCookieStore and domain matching
Jean-Christophe Collet
Jean-Christophe.Collet at Sun.COM
Mon Mar 17 08:05:32 PDT 2008
I filed CR 6644726 (Cookie management issues) after discovering a few
inconsistencies between the way J2SE handles cookies and the 'real
world'. I also have been working on a fix for that.
I thought all these issues were bugs, but one turned out to be a more
complicated.
It's actually the first one mentioned in the CR: the way domains are
matched.
In short, the actual code will not send cookies from the 'foo.com'
domain to the 'xxx.yyy.foo.com' site.
Which breaks a few sites, like Yahoo.
I initially thought that HttpCookie.domainMatches() was the culprit, but
I discovered that it actually follows RFC 2965 sec. 3.3.2 to the letter
as specified in the Javadoc.
So I don't think changing that code is the answer.
However, it should be noted that, in theory, that domain matching should
only used for RFC 2965 conform cookies. 'Old' cookies, as in the
netscape draft should behave differently.
After more research and consideration I would suggest to change our
implementation of CookieStore
(sun.net.www.protocol.http.InMemoryCookieStore) to take the cookie
version (as returned by HttpCookie.getVersion) when doing the domain
matching. In the case of a RFC 2965 cookie (version == 1) we would still
use HttpCookie.domainMatches(), in the case of a 'Netscape' cookie
(version == 0), we would use a slightly different comparison to allow
for the aforementioned situation.
I will produce proposed code changes soon, but I'd like to hear any
thoughts on that subject.
More information about the net-dev
mailing list