Build: 2001113008 Platform: Mac OS X 10.1.1 Carbon MRJ Plugin version: 1.0d6 Expected result: Cookies (for the document containing the applet) should be sent when using URLConnection. Actual results: No cookies are sent. This is a blocker for many applications as it breaks security mechanisms.

*** Bug 113500 has been marked as a duplicate of this bug. ***

See also bug 85827 This looks like an OSX-specific problem

Yes, this is OS X specific. It works fine using the Sun Java Plugin on other platforms (see bug 85827 and bug 79851). Patrick Beard is working on the Carbon MRJ Plugin in bug 88870. Reassigning to him. I don't see why bug 113500 was marked as a duplicate of this bug?

This bug and bug 113500 could probably be fixed with a common solution.

Patrick, should this bug be transfered to Brian?

minusing this bug, as per adt plug-ins triage. unlikely that we can get this fixed for next netscape release.

I think this will present a big problem to enterprise applications as the web server (or a servlet) cannot determine if the request comes from an authenticated user or not. We develop a content management system partly based on Java applets and our customers would love to be able to run it on their Macs as well as their Windows machines. But this will not happen until the plugin is able to send cookies when making connections to the server. What is the difficult part in fixing this bug? Are there missing interfaces from Apple are are there limitations in the MRJ plugin? I'm willing to help if someone can point me in the right direction.

Implementing Java protocol handlers will fix this bug. Marking dependent on bug #135840.

This problem seems to be the same with IE. Maybe a problem is the Apple MRJ itself ?

What's the status on this bug? I understand that fixing bug #135840 is not going to be easy. On Win32, Sun's Java Plugin uses a cookie service in the browser to determine what cookies to send along with the requests, iirc. Would that be a possible solution for OS X in the meantime, as fixing bug #135840 is probably going to take some time? A possible approach in Java may be (correct me if I'm wrong) to: Create a URLStreamHandlerFactory (and set it using URL.setURLStreamHandlerFactory()) that returns URLStreamHandlers that in turn returns URLConnections (from openConnection()) that by default: * Calls setRequestProperty("Cookies", <some Mozilla service that returns the cookies for the page>); * Calls setRequestProperty("User-agent", <some Mozilla service that returns the user agent string>); (This fixes bug #113500) * And then does the same thing as the default URLStreamHandlers. Ideas?

Just my 2c here, for people hitting this bug: 1) This happens on IE also, and I think may also happen on OS9; so if you're using those platforms, you'll need to work around this even if it gets fixed here. 2) We worked around this by passing the appropriate cookies along to the applet as a parameter, and then using the URLConnection.setCookie (I think), to set the cookie. Doing that seems to work reliably. It won't get the proper cookie states dynamically, but if you have the cookies you want when you load the applet, it works.

-> default assignee for old netscape assigned bugs.

This problem is fixed (on OS X) in Mozilla.org browsers that bundle version 0.9.6 or more recent versions of the Java Embedding Plugin. Apple's recent JVMs (1.4.2+) have a design flaw -- though they contain code to read and write the browser's cookie store, this code only works with Safari. JEP 0.9.6 (and later versions) work around this design flaw. For more information see item #1 in JEP 0.9.6's change log (which is bug 364158's attachment 248934 [details].

Here's a simple test applet that uses HTTP sessions (implemented in PHP) to show whether or not a given browser has access to the client browser's cookie store. PHP uses cookies to implement HTTP sessions. So its session support will break if it's used via the JVM's built-in browser, and the built-in browser doesn't have access (via the JVM) to the actual client browser's cookie store. The applet calls back to its server to display a simple web page inside the JVM's built-in browser -- one that displays the current session id and the number of times the session has been "re-visited" (i.e. the "count" variable). Click on the "Connect" button to make this happen. If the JVM's built-in browser has access to the client browser's cookie store, the "count" will increment every time the Connect button is pressed, and the session id will stay the same. But if the built-in browser can't access the client browser's cookie store, "count" will always be "1" and the session id will always be different. This applet's files need to be served from a web server that supports PHP.