Applet Installation in Java Plug-in 1.3
- Draft 3/7/99 -
Jerome
Dochez (dochez@eng)
- Revision 1 4/22/99
Stanley Ho (stanleyh@eng)
send feedback to dochez@eng or stanley.ho@eng
Introduction
In Java Plug-in 1.2, we support some limited applet caching by exploiting the native browser cache in which we are embedded. This is clearly enough for most users but some requested the ability to not depend on the browser cache.
Therefore, for big applet deployment a more reliable mechanism is necessary so applets can be "installed" on the end user machine under the control of the HTML tags. The goals for such a feature are :
- Versioning support
We must be able to detect either through the HTTP HEAD request on the applet resources or though a version tag that the applet needs to be upgraded from the web server.- Secure
The "installed" applet must still run within the AppletSecurityManager to have the same rights as a downloaded version.- Manageable
We need to provide tools to maintain the applet cache on the end user machine. These tools should be used to get various information on "installed" applets and the ability to flush them out the cache.
In order to reduce the changes and risks in the class loaders architecture, applet installation supports jar files only. For security reasons, we will not install applets downloaded using the HTTPS protocol.
HTML tags
In Java Plug-in 1.2, applets are cached in the browser cache. There is no need to specify extra tags information, this mechanism is applied by default for all .jar and .class files.
In Java Plug-in 1.3, for an applet to be installed in the Java Plug-in cache, the HTML provider needs to provide HTML tags. We propose to use the following HTML tag for this purpose :
<OBJECT .... >
<PARAM NAME="archive" VALUE="...">
......<PARAM NAME="cache_option" VALUE="...">
<PARAM NAME="cache_archive" VALUE="..."></OBJECT>
The cache_option attribute can take three values :
- No Disable applet installation, always download the file from the web server.
- Browser Run applets from browser cache. (Default)
- Plugin Run applets from Java Plug-in cache.
When Java Plug-in loads an applet, it should check this flag to determine how that JAR files are cached and how the applet is loaded. The versioning of the applet resources should rely on the normal HTTP HEAD request. We could have included a version number to the applet which would trigger a refetch of its resources but I does not add much. By using jar files, users can limit the applet loading to a couple of HEAD requests which should be very fast.
In some web servers, the HTTP HEAD respond may contain header information for controlling the caching algorithm, including "Cache-Control", "Expires", etc. When these HTTP headers are returned from the web server, it will always override the caching algorithm used by Java Plug-in. Please refer to HTTP 1.1 Specification Revision 6 Section 13 for more details.
The cache_archive attribute can have a list of jar files to be cached, e.g.
<PARAM NAME="cache_archive" VALUE="a.jar,b.jar,c.jar">
Similar to the archive attribute in the APPLET tag, the list of jar files in the cache_archive attribute do not contain the full URL. Rather, they are always downloaded from the codebase in the EMBED/OBJECT tag.
Notice that the list of JAR files in the cache_archive attribute can be totally orthogonal to the list of JAR files in the archive attribute in the EMBED/OBJECT tag. This is the result of supporting standard extension using class-path in MANIFEST because not all JARs are required to be listed in the archive attribute. There are three possible cases:
- JAR file is listed in cache_archive but NOT in archive: The JAR file is cached according to cache_option.
- JAR file is listed in archive but NOT in cache_archive: The JAR file is cached using the native browser cache, and this guarantee a minimum degree of caching.
- JAR file is listed in both cache_archive and archive: The JAR file is cached according to cache_option, because the caching mechanism is overriden by cache_option.
When the applet is loaded, the final archive for an applet is determined by the union of the list of JAR files in archive and cache_archive in the tag.
cache_option and cache_archive can only be specified once in a single EMBED/OBJECT tag, so each applet can only have one and only one type of cache_option for its cache_archive JAR files.
When the either cache_option or cache_archive is not present in the tag, Java Plug-in will not cache any JAR file through applet installation, and treat the applet normally using the archive attribute.
Issue: We could possibly eliminate cache_archive by applying the cache_option in all the JAR files in the archive attribute. We didn't do it that way because developers may want to "install" only a subset of JAR files in the archive attribute, rather than installing all the JAR files used by the applet.
Issue: We could potentially add options in the Java Plug-in Control Panel to override the cache_option flag. The user could choose between the following behaviours :
- Never
Independently of the cache_option flag, the applet should never be cached- Default
Use the cache_option flag values to cache.The property used to store this parameter will be named "javaplugin.global.cache"This could be an interesting RFE if we find out not having enough time to implement this.
Java Plug-in Cache
To ensure user protection, the Java Plug-in will use the "java.home" property to determine the location of the applet repository. The root directory for all installed applet should be called java_plugin_cache.
The structure of the cache will not be human-readeable. Each stored jar file should use the hash code of their URL as the file name. We could add in the future a dictionary to be able to browse the plug-in cache if necessary.
Tools
Java Plug-in Control Panel
The Java Plug-in Control panel should add an option to delete all the entries in the plug-in cache.
RFE: we could add tools to display the cache content to a finer grained detail and allow selective deletion.
Java Plug-in HTML converter
The HTML converter could be updated to add a check box to automatically add the cache_option and cache_archive param to the HTML tags.
Preliminary Design
In order to implement such a feature, we need to modify the current cache mechanism as it was implemented by Robert Szewczyk. The current design present major drawbacks that need to be addressed in order to implement the new features. These shortcomings are (but not limited to) :
- No pluggable caching mechanism
- The caching is implemented in HttpURLConnection which is called only for files loaded though the codebase or archive HTML tags.
- Caching algorithm is triggered entirely through interception, which is not reliable all the time.
When Java Plug-in 1.3 encounters cache_options and cache_archive in the EMBED/OBJECT tag, before the applet is actually loaded, the following will happen:
- Uses codebase and cache_options in the tag to determine if the list of JAR file in cache_archive can be loaded directly from the cache without connecting back to the web server. This happens if "Cache-Control" or "Expires" was previously set by the web server. Caching algorithm is determined by using cache_options and "javaplugin.global.cache" property.
- If the JAR files exists in the cache, but the files need to be revalidated by connecting back to the web server, a HTTP HEAD request will be sent to the web server to validate the JAR files in the cache. If the HTTP HEAD respond indicate that the JAR files are up-to-dated, they will be loaded directly from the cache.
- If the JAR files are not up-to-dated, or if the JAR files are not stored in the cache previously, Java Plug-in will perform a HTTP GET request to obtain the files and store them in the cache. If the respond header of the HTTP GET request contains any caching control header, e.g. "Cache-Control" or "Expires", it will override the Java Plug-in caching algorithm for this JAR file.
- This process continues until all the JAR files in the cache_archive are processed, then the actual applet loading process begins.
- Java Plug-in determines the final archive by using the union of the list of JAR files in archive and cache_archive in the tag.
- Java Plug-in stores the name of each JAR file in the cache_archive and its correponding caching info (caching handler, cache entry in the cache, etc) in the AppletClassLoader.
- Start loading the applet using the AppletClassLoader. If a JAR file needs to be loaded, always check the JAR caching info in the AppletClassLoader first. If the JAR file has been cached, load the JAR file directly from the cache using the stored caching info. Otherwise, download the JAR file into the native browser cache. This guarantee a minimum degree of caching.
In some JAR files, class-path attribute in the MANIFEST is used to load other JAR file, including standard extension. If these JAR files that contains the MANIFEST are specified in the cache_archive attribute, the referred JAR file will not be cached automatically using the cache_option, unless the referred JAR file is also listed in cache_archive, so no interception is required in Java Plug-in when referred JAR file is loaded.
If two applets happen to share the same classloader and use different cache_option for the same JAR file in the same browser session, e.g. two untrusted applets with the same codebase, the cache_option used in the JAR file in the first loading applet will always override, and the second applet will load the same JAR file using the cache_option specified by the first applet.
By using the approach above, all JAR files listed in the cache_archive will be validated before the applet is actually loaded. Because the applet is usually not able to load until it gets most of the JAR files, the overhead of validating the JAR files in the cache_archive should be small.
By default, Java Plug-in 1.3 will provide three caching mechanism implementation in the sun.plugin.caching package:
- NoCacheURLConnection
- BrowserCacheURLConnection
- PluginCacheURLConnection
Java Plug-in will look up the caching handler using reflection when it encounters the cache_option, and locate the handler <cache_option>CacheURLConnection in sun.plugin.cachescheme. This allows additional caching mechanism implementation to be plugged in easily in the future.