JDK-6349566 : java.net.CookieManager doesn't set default domain
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-11-14
  • Updated: 2011-02-16
  • Resolved: 2009-07-29
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 b62Fixed
Related Reports
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-beta-b59)
Java HotSpot(TM) Client VM (build 1.6.0-beta-b59, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
The CookiePolicy used by java.net.CookieManager by default rejects JSESSIONID cookies generated by servlet engines (e.g. Tomcat 5.5.9 in my testing).

I would suggest that the default CookiePolicy allow cookies whose domain is 'null' like JSESSIONID.  Whether this change belongs in HttpCookie.domainMatches(), CookiePolicy.ACCEPT_ORIGINAL_SERVER, or CookieManager.<init>(CookieStore,CookiePolicy) I'll leave to the Sun developers but given the importance of JSESSIONID in the world of Java not accepting it by default is very problematic.

Also, it should be noted in the documentation that java.net.CookieManager is not installed by default.  Further if java.net.CookieManager's default policy is *not* going to be changed to handle session cookies by default, then the documentation should also clearly and explicitly state this!  Not clearly documenting this behavior will lead to client developers accidentally triggering the creation of thousands of sessions when attempting to programmatically operate against web applications.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Install java.net.CookieManager as the default cookie handler.
2) Make repeated HTTP connection(s) to a web app URL which generates sessions.
3) Note that the CookiePolicy used rejects JSESSIONID.  [One easy way to note this is to do (2) in a loop and see the number of active sessions rise uncontrollably in your servlet engine.  Another is to use a debugger :-)]

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JSESSIONID should be accepted by default.  It is too critical of a cookie to reject out-of-the-box.

Also if java.net.CookieManager is not going to be installed out-of-the-box in non-applet non-web-start scenarios then this should be clearly documented.
ACTUAL -
JSESSIONID is rejected by java.net.CookieManager by default.

Moreover java.net.CookieManager is not installed by default and this is not noted in the documentation.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Install java.net.CookieManager with your own CookiePolicy (e.g. one that accepts cookies with a null domain but otherwise behaves like CookiePolicy.ACCEPT_ORIGINAL_SERVER).

This is not acceptable, however, in that it leaves a default behavior that is completely inappropriate for use with web applications.

Comments
EVALUATION Right. CookieManager should enforce the default domain as per RFC 2965. Will fix as soon as possible.
16-04-2009

EVALUATION The statement about appservers setting the domain is just plain wrong, many servers *don't* set the domain - for example Sun-Java-System-Web-Server/6.1 which is used to run http://www.sun.com! Apart from that, the current behaviour of CookieManager + CookiePolicy.ACCEPT_ORIGINAL_SERVER is not compliant with RFC 2965, which is clearly a bug: ---------- 3.2.2 Set-Cookie2 Syntax : Domain=value OPTIONAL. The value of the Domain attribute specifies the domain for which the cookie is valid. If an explicitly specified value does not start with a dot, the user agent supplies a leading dot. ---------- ---------- 3.3 User Agent Role The user agent applies these defaults for optional attributes that are missing: : Domain Defaults to the effective request-host. (Note that because there is no dot at the beginning of effective request-host, the default Domain can only domain-match itself.) ---------- So according to RFC 2965 it is not mandatory for the server to set the domain, and if it is not set it defaults to the domain of the request-host. CookiePolicy.ACCEPT_ORIGINAL_SERVER does *not* do this, if the domain is not set there is no code to default to the domain of the requestor: public static final CookiePolicy ACCEPT_ORIGINAL_SERVER = new CookiePolicy(){ public boolean shouldAccept(URI uri, HttpCookie cookie) { return HttpCookie.domainMatches(cookie.getDomain(), uri.getHost()); } };
31-12-2007

EVALUATION This problem is easily worked around by creating the CookieManager with a policy of CookiePolicy.ACCEPT_ALL. Many appserver actually include domain information with their JSESSION cookie, SunOne appserver for example. Accepting cookies without a domain is a potential security risk and as so it is up to the developer to allow this. *** (#1 of 1): [ UNSAVED ] ###@###.###
15-12-2005

WORK AROUND One workaround is to cook one's own CookiPolicy impl.
15-11-2005