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

Question

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 % 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.

Answer 1

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.