JDK-6644726 : Cookie management issues
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6,6u3
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_nevada
  • CPU: generic,other
  • Submitted: 2007-12-21
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b27Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
1) HttpCookie.domainMatches(String domain, String host) seems broken.
  Specifically it returns 'false' when domain is ".yahoo.com" and host is "cm.my.yahoo.com"
  The error is in the following code:

       else if (lengthDiff > 0) {
           // need to check H & D component
           String H = host.substring(0, lengthDiff);
           String D = host.substring(lengthDiff);

           return (H.indexOf('.') == -1 && D.equalsIgnoreCase(domain));
       }

 In here lengthDiff is the length difference between host and domain. So H becomes "cm.my" and D becomes ".yahoo.com" which is OK.
 Except for the following line where it specifically test for an absence of '.' in H, which is wrong.

2) InMemoryCookieStore uses the full URI as a search index , including the scheme. So cookies don't cross over from http://foo.com to https://foo.com and vice versa. It also uses the port number. Both are in contradiction with the RFC.

3) CookieManager/InMemoryCookieStore don't take into account the "Secure" tag of cookies. When a cookie is tagged "Secure" it should only be sent if the scheme is https. Right now, this is ignored when returning cookies.
4) The "expires" field is parsed a bit too strictly. It expects the date to be in the "EEE, dd-MMM-yyyy HH:mm:ss GMT", therefore rejects cookies set with a slightly different format (e.g. from Yahoo:  'FPS=ds;expires=Wed, 19 Aug 2015 16:00:00 GMT;path=/;domain=www.yahoo.com', notice the absence of '-').
5) The CookieManager doesn't attribute a default path to the cookies. When no 'path' is explicitely specified, specs say the path should be the directory of the document. E.G. for a cookie whose doc URI is 'http://www.foo.bar/dir/page/doc.html' the default path should be '/dir/page'.
6) If CookieManager.get() is called with an URI that does not contain a path, e.g "http://www.sun.com" instead of "http://www.sun.com/", it does not return any cookies, even if CookieManager contains cookies for the URI.

The relevant code is:

    /*
     * path-matches algorithm, as defined by RFC 2965
     */
    private boolean pathMatches(String path, String pathToMatchWith) {
        if (path == pathToMatchWith)
            return true;
        if (path == null || pathToMatchWith == null)
            return false;
        if (path.startsWith(pathToMatchWith))
            return true;

        return false;
    }

That needs to cater for the case where path is the empty string.
7) the 'Port' optional attribute is not enforced by the CookieManager. It should be checked before sending cookies with a HTTP request. See RFC 2965 sections 3.2.2, 3.3.1 and 3.3.2.

Comments
EVALUATION Note that the first issue is actually related to whether the cookie conforms to Netscape draft specs or to RFC 2965. So, it depends on the version of the HttpCookie.
17-04-2008

EVALUATION See Description. Will fix in JDK7 as soon as possible.
21-12-2007