-
Bug
-
Resolution: Duplicate
-
P2
-
None
-
6u20
FULL PRODUCT VERSION :
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
EXTRA RELEVANT SYSTEM CONFIGURATION :
Windows XP session running in Citrix Terminalserver environment
A DESCRIPTION OF THE PROBLEM :
I 'have an unsigned applet which opens URLConnections to the server it was loaded from. The applet was running with different JREs up to 1.5.0_xx. After upgrading to 1.6.0_20 the applet hangs. The last trace information in the java console before it hangs show two http requests:
network: Connecting http://<myclient>/crossdomain.xml with Proxy=DIRECT
network: Connecting von http://<myclient>:80/ with Proxy=DIRECT
When calling these URLs in a web browser on the same machine, the browser gets no response, it's waiting forever. I guess that's what happens to the applet, it's waiting for a response that never will come.
Now, why is java plugin doing these http requests pointing to the client machine where the applet is running? This makes no sense for me. It will never get a response, because there is no webserver running on this machines. I guess it would be the best to avoid these useless http requests (or at least implement a timeout and then continue normally with the restrictions of an unsigned applet).
Btw, the problem only exists in our Citrix terminalserver environment. On many other workstations the applet still works. On these workstations, calling the two URLs in a browser results in an immediate error message, but no hangs. So it seems we have a different (networking?) situation in our Citrix environment. But nevertheless behaviour of the java plugin is really problematic.
This problem seems to be much the same as bug ID 6810480, which is closed with no further information.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Workaround from bug ID 6810480 works: creating .java.policy file with
granting java.security.AllPermission to the server-codebase.
Release Regression From : 6u20
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
EXTRA RELEVANT SYSTEM CONFIGURATION :
Windows XP session running in Citrix Terminalserver environment
A DESCRIPTION OF THE PROBLEM :
I 'have an unsigned applet which opens URLConnections to the server it was loaded from. The applet was running with different JREs up to 1.5.0_xx. After upgrading to 1.6.0_20 the applet hangs. The last trace information in the java console before it hangs show two http requests:
network: Connecting http://<myclient>/crossdomain.xml with Proxy=DIRECT
network: Connecting von http://<myclient>:80/ with Proxy=DIRECT
When calling these URLs in a web browser on the same machine, the browser gets no response, it's waiting forever. I guess that's what happens to the applet, it's waiting for a response that never will come.
Now, why is java plugin doing these http requests pointing to the client machine where the applet is running? This makes no sense for me. It will never get a response, because there is no webserver running on this machines. I guess it would be the best to avoid these useless http requests (or at least implement a timeout and then continue normally with the restrictions of an unsigned applet).
Btw, the problem only exists in our Citrix terminalserver environment. On many other workstations the applet still works. On these workstations, calling the two URLs in a browser results in an immediate error message, but no hangs. So it seems we have a different (networking?) situation in our Citrix environment. But nevertheless behaviour of the java plugin is really problematic.
This problem seems to be much the same as bug ID 6810480, which is closed with no further information.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Workaround from bug ID 6810480 works: creating .java.policy file with
granting java.security.AllPermission to the server-codebase.
Release Regression From : 6u20
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.