SSL confirmation dialog popup auto closes in IE8 when re-accessing a JNLP file
- by haylem
I'm having this very annoying problem to troubleshoot and have been going at it for way too many days now, so have a go at it.
The Environment
We have 2 app-servers, which can be located on either the same machine or 2 different machines, and use the same signing certificate, and host 2 different web-apps.
Though let's say, for the sake of our study case here, that they are on the same physical machine. So, we have:
https://company.com/webapp1/
https://company.com/webapp2/
webapp1 is GWT-based rich-client which contains on one of its screens a menu with an item that is used to invoke a Java WebStart Client located on webapp2. It does so by performing a simple window.open call via this GWT call:
Window.open("https://company.com/webapp2/app.jnlp", "_blank", null);
Expected Behavior
User merrilly goes to webapp1
User navigates to menu entry to start the WebStart app and clicks on it
browser fires off a separate window/dialog which, depending on the browser and its security settings, will:
request confirmation to navigate to this secure site,
directly download the file,
and possibly auto-execute a javaws process if there's a file association, otherwise the user can simply click on the file and start the app (or go about doing whatever it takes here).
If you close the app, close the dialog, and re-click the menu entry, the same thing should happen again.
Actual Behavior
On Anything but God-forsaken IE 8
(Though I admit there's also all the god-forsaken pre-IE8 stuff, but the Requirements Lords being merciful we have already recently managed to make them drop these suckers. That was close. Let's hold hands and say a prayer of gratitude.)
Stuff just works. JNLP gets downloaded, app executes just fine, you can close the app and re-do all the steps and it will restart happily. People rejoice. Puppies are safe and play on green hills in the sunshine. Developers can go grab a coffee and move on to more meaningful and rewarding tasks, like checking out on SO questions.
Chrome doesn't want to execute the JNLP, but who cares? Customers won't get RSI from clicking a file every other week.
On God-forsaken IE8
On the first visit, the dialog opens and requests confirmation for the user to continue to webapp2, though it could be unsafe (here be dragons, I tell you). The JNLP downloads and auto-opens, the app start. Your breathing is steady and slow.
You close the app, close that SSL confirmation dialog, and re-click the menu entry. The dialog opens and auto-closes. Nothing starts, the file wasn't downloaded to any known location and Fiddler just reports the connection was closed. If you close IE and reach that menu item to click it again, it is now back to working correctly. Until you try again during the same session, of course.
Your heart-rate goes up, you get some more coffee to make matters worse, and start looking for plain tickets online and a cheap but heavy golf-club on an online auction site to go clubbing baby polar seals to avenge your bloodthirst, as the gates to the IE team in Redmond are probably more secured than an ice block, as one would assume they get death threats often. Plus, the IE9 and IE10 teams are already hard at work fxing the crap left by their predecessors, so maybe you don't want to be too hard on them, and you don't have money to waste on a PI to track down the former devs responsible for this mess.
Added Details
I have come across many problems with IE8 not downloading files over SSL when it uses a no-cache header. This was indeed one of our problems, which seems to be worked out now. It downloads files fine, webapp2 uses the following headers to serve 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"); // please exec me
As you might have inferred, we get some confirmation dialog because there's something odd with the SSL certificate. Unfortunately I have no control over that. Assuming that's only temporary and for development purposes as we usually don't get our hands on the production certs. So the SSL cert is expired and doesn't specify the server. And the confirmation dialog. Wouldn't be that bad if it weren't for IE, as other browsers don't care, just ask for confirmation, and execute as expected and consistantly.
Please, pretty please, help me, or I might consider sacrificial killings as an option. And I think I just found a decently prized stainless steel golf-club, so I'm right on the edge of gore.
Side Notes
Might actually be related to IE8 window.open SSL Certificate issue. Though it doesn't explain why the dialog would auto-close (that really is beyong me...), it could help to not have the confirmation dialog and not need the dialog at all. For instance, I was thinking that just having a simple URL in that menu instead of have it entirely managed by GWT code to invoke a Window.open would solve the problem. But I don't have control on that menu, and also I'm very curious how this could be fixed otherwise and why the hell it happens in the first place...
