Why does Java WebStart application refuse to start if JNLP url contains %?

8
votes

I've noticed a curious thing while trying to dynamically generate JNLP files based on URL parameters passed to a HTTP server. If I have something like this in my HTML code, it works:

<embed type="application/x-java-applet;" launchjnlp="dummy.jnlp"/>

If on the other hand I have a % character in the launchjnlp attribute, the plugin simply won't do anything:

<embed type="application/x-java-applet;" launchjnlp="dummy%3f.jnlp"/>

No error messages, no default Java splash screen, nothing, it silently fails. (Without even attempting to retrieve the JNLP file.)

Is this some kind of security feature? If it is, what is it supposed to guard against?
Or could it be a straightforward bug?

Update: Using the &#37; entity instead of a % sign doesn't work either.
Update 2: I tried and failed to find any documentation on the exact semantics of the launchjnlp attribute, but the entire tag is generated by deployJava.launchWebStartApplication(jnlp), which is supposedly the "official" way of launching a Web Start application from a browser.
Update 3: Just to be absolutely crystal clear about this: the above example is just that: an example. You can observe the described behaviour with absolutely any URL (relative, absolute, file://, http://, you name it), any url-encoded character, or even an invalid escape sequence (though in that case it's more or less justified), the existence or absence of an actual JNLP file is irrelevant, because we don't even get to the point where the plugin would attempt to load the JNLP file.

1
javajava-web-startjnlp
Did you try using the HTML entity &#37;? - Obicere
@Obicere I've just tried it and it doesn't work either. Not that surprising given that I'd expect the entity to be resolved before it reaches the Java plugin. - biziclop
@davida.I am aware of that, and that is exactly what I want to do: urlencode a parameter. But as you can see, as soon as I put an encoded character in the url (%3f -> ? in this case), things break. Note that the behaviour is same regardless of whether I provide a valid escape sequence or not, so dummy%.jnlp will also fail. - biziclop
@StefanHaustein That attribute can (in theory) contain any valid URL, therefore a question mark is perfectly reasonable thing to have in it. I just constructed these examples for demonstration but in the real scenario the URL looks like http://.../something.jnlp?param=<url encoded string>. And yes, the workaround was to use my own non-standard method of escaping (well, base64), but the question is about why am I forced to do this. - biziclop
@Ben Please, pretty please, it is just an example. You can replace it with any character you like in any position of any file name. It can be a real file if you like, or a non-existent file if you prefer, it can be a http url, a https url, anything you fancy, but as soon as you put a single % character anywhere, it stops working. - biziclop

1 Answers

6
votes

Is this some kind of security feature? If it is, what is it supposed to guard against? Or could it be a straightforward bug?

From what I can uncover, 'straightforward bug' is the answer. Here's the issue page:

https://bugs.openjdk.java.net/browse/JDK-8043409

It looks like it's not scheduled to be fixed until the release of JDK 9.

I'd suggest trying a different JDK implementation, but that seems unlikely to change anything given the amount of code shared between the Oracle and OpenJDK implementations and the fact that the WebStart code appears to be proprietary/closed-source.

So the workaround you devised with base64-encoding is probably the best option for now. If you have to do this often, maybe the encoding step can be rolled into the deployJava.launchWebStartApplication(jnlp) JavaSript API so that it happens automatically if/when needed.