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.
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.
- relates to
-
JDK-6644726 Cookie management issues
-
- Closed
-
-
JDK-6865629 Backport JDK 7 Cookie fixes to JDK 6
-
- Closed
-