JDK-8139389 : Register a protocol handler for Java Webstart
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u60
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_8
  • CPU: x86
  • Submitted: 2015-10-08
  • Updated: 2016-10-06
  • Resolved: 2016-01-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u101Fixed 9 b105Fixed
Related Reports
Duplicate :  
Relates :  
Some browsers like Google Chrome and Microsoft Edge make it very difficult to launch a JNLP file with Java Webstart.
We came across another solution that should overcome this issue in most cases. It is based on defining an own protocol handler for Java Webstart.
In the following example we use a protocol named "jnlp" which can be used within an HTML page or Javascript:

���	The URI is "jnlp:http://myjnlpfile.jnlp"
���	The browser will search for a protocol handler "jnlp" in the operating system and execute the registered application
���	The command may look like this: "javaws.exe jnlp:http://myjnlpfile.jnlp"

The "Javaws.exe" does not understand the argument "jnlp:http://myjnlpfile.jnlp".
Nevertheless it should be less complicated to remove the prefix "jnlp:" within the code of "Javaws.exe". 
Furthermore it would be helpful that Java supports "data" URI's in general.
We could then launch a Java Webstart file coming a script running in the browser:

���	The "data" URI is "data:application/x-java-jnlp-file;base64,PGpubHAgc3BlYz0iMS4wKyIgY29kZWJhc2U9Imh0dHBzOi8vZXhhbXBsZS5jb20iPi4uLjwvam5scD4="

���	The resulting "jnlp" URI is "jnlp:data:application/x-java-jnlp-file;base64,PGpubHAgc3BlYz0iMS4wKyIgY29kZWJhc2U9Imh0dHBzOi8vZXhhbXBsZS5jb20iPi4uLjwvam5scD4="

It would be great if the Java installer could register a protocol handler for Java Webstart as described above.

Here are some links which decribe how to register protocol handlers amongst operating systems:
���	https://msdn.microsoft.com/library/aa767914(v=vs.85).aspx
���	http://superuser.com/questions/548119/how-do-i-configure-custom-url-handlers-on-os-x
���	http://stackoverflow.com/questions/18534591/how-to-register-a-url-protocol-handler-in-node-js

We already tested protocol handlers successfully with:
���	Mozilla Firefox
���	Internet Explorer
���	Microsoft Edge
���	Google Chrome
���	Opera

Since support for applets is declining, we have to rely on other ways to start java applications over the web.

crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-1702 test case added to http://oklahoma.us.oracle.com/www/tests/jnlp/test.html.

on further reflection, it has to be base64 encoded, since it is xml, and the xml tags themselves cannot be percent encoded. so if it must be type application/x-java-jnlp-file, and it must be base64 encoded, we could just ignore everything before the comma for now, and assume the rest is a base 64 encoded jnlp file.

the normally specified syntax for a data URI is: data:[<media type>][;charset=<character set>][;base64],<data> I think if we implement we should support at least: media type application/x-java-jnlp-file or none, given that full url is "jnlp:<data URI>" I think we can assume it implies media type application/x-java-jnlp-file. ;base64 or not, ie either jnlp file in plain text, or base64 encoded. The <data> is a sequence of octets represented as characters where: "Permitted characters within a data URI are the ASCII characters for the lowercase and uppercase letters of the modern English alphabet, and the Arabic numerals. Octets represented by any other character must be percent-encoded, as in %26 for an ampersand" So you could implement a jnlp file without base 64 encoding, but may need to percent encode many characters.

For the first part, implementing URLscheme handler for "jnlp:<URL>", there very simple fix can be demonstrated by last two tests on: http://oklahoma.us.oracle.com/www/tests/jnlp/test.html. The second request is interesting also: "jnlp:data:application/x-java-jnlp-file;base64,PGpubHAgc3 ... am5scD4=" where "PGpubHAgc3 ... am5scD4=" is base64 encoded jnlp file. this is fundamentally the same as embedded_jnlp applet param we have in plugin, except for javaws and avoids using any DT or DTLite plugin. would also be easy to implement (all in one place, LaunchDescFactory.filterUrlFile()) just need to agree if the above syntax is correct "jnlp:data:<mime type>;<encoding>,<encoded content>"

Although this was fundamentally implemented as JDK-8055464, this RFE suggests an alternate implementation, where jnlp:http://host.com/path and jnlp://https://host.com/path are used instead of what we implemented in 8055464 (jnlp://host.com/path and jnlps://host.com/path) since we could very easily implement both syntax's, I am re-opening this RFE as request to implement the other as suggested above.