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