JDK-6990877 : Need way to cache JNLP content in the object/applet tag
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2010-10-10
  • Updated: 2011-11-15
  • Resolved: 2011-05-18
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.
JDK 7
7 b126Fixed
Related Reports
Relates :  
JDK-7005789 - Umbrella: Common Deployment code update for supporting Fx applications
Description
There should be a way to provide most of details in the JNLP file as part of the applet/object tag 
(ideally embed JNLP file). In that case we do not need to load JNLP and can start from content cached in the web page.
Comments
EVALUATION Suggested release note blurb: Optional applet parameter 'jnlp_embedded' provide option to cache JNLP content on the HTML page and shortens applet launch time by skipping an network access. The parameter 'embedded_jnlp' has as value the base64 encoded content of the applet JNLP file. For example: <applet width="710" height="540" > <param name="jnlp_href" value="launch.jnlp"/> <param name="jnlp_embedded" value="PD94bWwgdmVyc2lvbj0iMS4wIiB . . . dC1kZXNjPg0KPC9qbmxwPg0K"/> <param name="draggable" value="true"/> </applet> When present, parameter 'jnlp_embedded' value replaces content of JNLP pointed to by param 'jnlp_href'. The value of 'jnlp_ref' is then optional and only used as backup when content of 'jnlp_embedded' is invalid. There are a few restrictions on the embedded JNLP content: (1) attribute href from element jnlp should be relative. (2) attribute codebase from element jnlp should be empty (which means the codebase value will be derived from document base URL).
20-01-2011
EVALUATION Design submitted for security review on 12/29/10: As part of 7 performance improvement for cold start of JNLP applets, the deployment team plans to introduce an optional applet parameter called 'embedded_jnlp' which would have value of base64 encoded content of the applet JNLP file. <applet width="710" height="540" > <param name="jnlp_href" value="launch.jnlp"/> <param name="embedded_jnlp" value="PD94bWwgdmVyc2lvbj0iMS4wIiB . . . dC1kZXNjPg0KPC9qbmxwPg0K"/> <param name="draggable" value="true"/> </applet> The applet param 'embedded_jnlp' provides an option to skip a network access for JNLP file content and shorten the applet launch time. On cold starts, the base64 decoded value would be the initial JNLP content contributing to the final applet launch info. The embedded JNLP would be cache for subsequent warm starts of the applet, either from the web page or from the shortcut. On warm starts, if needed, the embedded JNLP content will be used to update the cached JNLP. In terms of security, since the JNLP client did not directly load the JNLP content from a location, it could not validate a codebase with absolute URL. To mitigate this we restrict embedded JNLP content to use only empty codebase, which would eventually resolves into the docbase URL. This would prevent malicious applet from faking codebase. If the app jar is signed, launch info from embedded JNLP would go through the same signing validation as normal JNLP file content. Similarly, for unsigned applets, unrestricted accesses are prevented. With the above design and consideration, we don't see that allowing embedded JNLP content on a web page, would create new security holes. We would appreciate if the security team review to make sure that it is indeed safe.
05-01-2011
EVALUATION Proposed approach: 1) Support optional jnlp_content param to the applet tag. The value is base64-encoded content of JNLP descriptor. 2) If value is present then client VM should use this descriptor instead of loading it from the network. Potential implementation issues: 1) base64 version of JNLP can be potentially long - need to understand what is the limit here. 2) client VM may need to be restarted - value should not be lost? or be in cache? 3) Deployment code may try to get main JNLP from URL more than once. Need to make sure these request do not cause network lookups. (this could depend on value of update tag) 4) Subsequent launch of the app should not require new network lookups. Even if app is launched not from origibal web page. E.g. from desktop shortcut it created 5) If we will cache given content in the cache. What URL we will use? Hopefully docbase & filename (need to make sure filename is always relative) => it should not be possible to use this way to add arbitrary content to the cache for arbitrary URL.
06-12-2010