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.

Mimicry

Did you try using the HTML entity %? – Coat

@Coat 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. – Mimicry

In URL, the % sign is used to mark a start of a URL encoded character. To have a literal % in an URL, you have to URL-encode it (that is - replace the % with %25). See en.wikipedia.org/wiki/Percent-encoding – Extenuatory

@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. – Mimicry

Can't you just use your own encoding, e.g. map ? to _3f, _ to _5f etc? Having question marks in file names seems like something that may fail / cause trouble at many levels.... – Labor

sorry, i don't get it...where can i find the documentation to this attribute launchjnlp? where does it come from? Maybe this attribute just expects a filename as is – Birdiebirdlike

@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. – Mimicry

@Birdiebirdlike The attribute (and indeed the entire tag) is created by Oracle's deployJava.js, and it has to be a URL. – Mimicry

Sorry, i feel i bit stupid...is dummy%3f.jnlp really the filename? and this file exists? i am asking because it looks strange to me(maybe its too late)...at least when this should be a parameter before the .jnlp – Birdiebirdlike

beside that, where are these parameters parsed? inside the jnlp? – Birdiebirdlike

@Birdiebirdlike It doesn't have to exist to see the difference in behaviour: just try the two tags in a html page you create locally: in the first case the plugin will complain about the missing JNLP file, in the second it won't even attempt to find it. – Mimicry

@Birdiebirdlike The parameters are parsed on the server side and are used to dynamically generate the JNLP file, but that's besides the point really as the plugin doesn't even attempt to contact the server if there's a % character in the URL. – Mimicry

Why are you using %3F in the first place? Why not ?? – Handedness

@EJP I've already explained in a comment above, but I'd really want to steer us back to the real question: i.e. why can I NOT use it if I so wish. – Mimicry

are you sure it is dummy%3f.jnlp instead of dummy.jnlp%3f, (parameters are added to the end, as far as i know) in case of URLEncode, this %3F (?) converts to dummy?.jnlp.(this filename is invalid in Windows) Maybe this causes problems when using on local filesystem? – Birdiebirdlike

@Birdiebirdlike 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. – Mimicry

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.

Levulose

Thank you, I didn't know the plugin implementation was closed source. Oh well. – Mimicry