FULL PRODUCT VERSION :
I have not had a chance to test the problem with other releases. Since 
it relates to the interaction between the Java plugin and Internet 
Explorer, and Microsoft changed the behavior of some of the APIs that 
allow retrieval of cookies (see 
http://msdn.microsoft.com/en-us/library/aa384321(VS.85).aspx and 
http://msdn.microsoft.com/en-us/library/aa384710(VS.85).aspx), I would 
imagine it applies to all releases.

The specific release I saw the problem on was 1.6.0_07. However, since 
the plugin was rearchitected in 1.6 Update 10, it's possible this was 
fixed in this release.


ADDITIONAL OS VERSION INFORMATION :
Windows XP

EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 6.0, Firefox 3.0

A DESCRIPTION OF THE PROBLEM :
Previous, when making a request using URLConnection, all cookies that were sent to the browser were transferred to the URLConnection request without any intervention from the developer. This allowed session cookies to be transparently shared between the web browser and an applet.

IE 6.0 and Firefox 3.0 added support for the HttpOnly cookie property, which prevents these cookies from being accessible to server-side scripts. The goal was to prevent cross-site scripting attacks.

Since the introduction of this support in these browsers, Java applets ignore all cookies marked HttpOnly. (The JVM is likely getting these cookies from the same place the scripting engines request these). This prevents Java applets from including these cookies in server requests made with URLConnection.

Since ASP.Net 2.0 was released, all session cookies in ASP.Net are marked HttpOnly by default (a setting which cannot be changed). J2EE and PHP have also added similar settings.

Since applets cannot read HttpOnly cookies and do not include them in URLConnection requests, access to the web server is done in a separate session, which may include deny access to the requested resource entirely.

The problem appears as a subtle one, where the session is suddenly lost in these browsers. Only detailed analysis of the headers being sent and received allowed us to identify it as an HttpOnly problem.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create an applet which opens a URLConnection back to the web server.
2. Place the applet on a page the user needs to log in to see.
3. Use a framework configured to set HttpOnly on the session cookies
4. Use "Live HTTP Headers" Firefox extension, or other method, to monitor the headers being sent.
5. Turn on tracing and debugging in the Java console.
6. Log into the application. The Set-Cookie headers will be sent with the HttpOnly attribute. When the applet opens a URLConnection back to the server, all cookies except those set with HttpOnly will be included in the request.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
There is no applet-side workaround. Certain web applications can be hacked to prevent them from sending the HttpOnly attribute with cookies. However, this enables certain cross-site scripting security holes that HttpOnly was designed to prevent.
--
Note: One good fix would be to include ALL cookies, regardless of their HttpOnly status, when making URLConnection connections, but only including non-HttpOnly cookies when accessing the cookies programatically from Java (thus avoiding cross-site scripts from taking advantage of Java's access to the cookies).
Same issue reported by a CAP member -

For security reasons we have to upgrade our webapplication (large
eGovernment portal with > 1M users, using applets)
to HttpOnly cookies. 

Unfortunately this upgrade breakes communication
between applets and the server because the
java plugin omits cookies flagged with "HttpOnly" when opening an
URLConnection.

This is a serious issue which prevents us from offering an eGovernment
portal with up-to-date security standards.