I had this very nasty problem for troubleshooting and went on for too many days, so go through it.
Environment
We have 2 server applications that can be located on the same computer or on two different machines and use the same signature certificate and host 2 different web applications.
Although, let's say, for the sake of our research here, that they are on the same physical machine. So we have:
webapp1 is a rich GWT-based client that contains on one of its screens a menu with an element that is used to call the Java WebStart client located on webapp2 . He does this by making a simple window.open call through this GWT call:
Window.open("https://company.com/webapp2/app.jnlp", "_blank", null);
Expected Behavior
- Merrilly goes to
webapp1 - The user goes to the menu entry to launch the WebStart application and clicks on it.
- The browser launches a separate window / dialog, which, depending on the browser and its security settings, will:
- request confirmation to go to this secure site,
- directly upload the file
- and maybe automatically execute the
javaws process if there is a file association, otherwise the user can just click on the file and start the application (or continue to do whatever he does here).
- If you close the application, close the dialog box and click the menu item again, then repeat the same thing again.
Actual behavior
About anything but God-forgotten IE 8
(Although I admit there also all things left by pre-IE8 god, but the Lords of Requirements, which are mercy, we have recently managed to get them to drop these suction cups. It was close. Let them sit in their hands and say a prayer of thanks.)
It just works. JNLP loads, the application runs fine, you can close the application and complete all the steps, and it will restart with joy. People are happy. Puppies are safe and play on green hills in the sun. Developers can go get coffee and move on to more meaningful and useful tasks, for example, check on SO questions.
Chrome doesn't want to run JNLP, but who needs it? Clients do not receive RSI from a file click every two weeks.
About God Forgotten IE8
At the first visit, a dialog box opens and a confirmation is requested for the user to continue webapp2 , although it may be unsafe (for example, dragons for you). JNLP loads and automatically opens, the beginning of the application. Your breathing is steady and slow.
Close the application, close the SSL confirmation dialog box and click the menu item again. The dialog opens and closes automatically. Nothing starts, the file was not uploaded to any known location, and Fiddler simply reports that the connection was closed. If you close IE and get to this menu item to click it again, it will return to working properly. Until you try again during the same session, of course.
Your heart rate rises, you get some more coffee to make matters worse, and start looking for simple tickets online and a cheap but heavy golf club at an online auction to go to club baby seals to avenge the bloodshed as the gates to the team Redmond IEs are probably better off than the ice block, as it can be assumed that they often receive death threats. In addition, the IE9 and IE10 teams are already working hard on the crap left by their predecessors, so maybe you don’t want to be too strong, and you don’t have the money to spend on PI to track down the former developers responsible for this mess.
Information Added
I ran into a lot of problems with the fact that IE8 does not download files via SSL when it uses the no-cache header. In fact, this was one of our problems, which seems to have been worked out now. It downloads files perfectly, webapp2 uses the following headers to work with the JNLP file:
response.setHeader("Cache-Control", "private, must-revalidate"); // IE8 happy response.setHeader("Pragma", "private"); // IE8 happy response.setHeader("Expires", "0"); // IE8 happy response.setHeader("Access-Control-Allow-Origin", "*"); // allow to request via cross-origin AJAX
response.setContentType ("application / x-Java-JNLP file"); // request to execute me
As you might expect, we get a confirmation dialog because there is something strange with the SSL certificate. Unfortunately, I do not control this. Assuming this is only temporary and for development purposes, since we usually do not receive our production certificates. Therefore, the SSL certificate has expired and does not indicate a server. And a confirmation dialog. It wouldn’t be so bad if it weren’t for IE, as other browsers don’t care, just ask for confirmation and execute as expected and sequentially.
Please help me, or I can consider sacrificial killings as an option. And I think I just found a suitable stainless steel golf club, so I'm right on the edge of the mountains.
Side notes
Perhaps this is due to the IE8 window.open SSL Certificate problem. Although this does not explain why the dialog will be automatically closed (which is really me ...), it might help not to have a confirmation dialog and not need a dialog at all. For example, I thought that just having a simple URL in this menu, instead of completely controlling the GWT code to call Window.open, would solve the problem. But I have no control over this menu, and I am also very curious how this could have been fixed otherwise and why the hell is this happening first ...