We have a case where clients seem to be eternally caching versions of applets. We're making use of the <param name="cache_version">
tag correctly within our <object>
tag, or so we think. We went from a version string of 7.1.0.40
to 7.1.0.42
and this triggered a download for only about half of our clients.
It doesn't seem to matter which version of the JRE the client is running. We've seen people have this problem on 1.4, 1.5 and 1.6.
Does anybody have experience with explicit cache versions? Does it work more reliably (ignoring speed) to instead rely on the cache_archive
's "Last-Modified" and/or "Content-Length" values (as per Sun's Site)?
FYI, object block looks like this:
<object>
<param name="ARCHIVE" value="foo.jar">
<param name="CODE" value="com.foo.class">
<param name="CODEBASE" value=".">
<param name="cache_archive" value="foo.jar">
<param name="cache_version" value="7.1.0.40">
<param name="NAME" value="FooApplet">
<param name="type" value="application/x-java-applet;jpi-version=1.4.2_13">
<param name="scriptable" value="true">
<param name="progressbar" value="true"/>
<param name="boxmessage" value="Loading Web Worksheet Applet..."/>
</object>
As per this link , same jar file should not be listed int "archive" and "cache_archive" params. In that case, the JAR file is cached using the native browser cache.
You can remove applet from Java cache using
Java Control Panel
.For example, on Win XP
Unfortunately, different versions of the Java Plug-In have different caching behaviors. Setting your Cache-Control and Last-Modified HTTP headers is the ideal solution, but it only works under the most recent versions of the JRE.
The only solution GUARANTEED to work is to rename your application jars when their versions change (we've seen strange caching behavior when trying other tricks like adding query strings based on file dates). This isn't so difficult to do if you have a properly automated deployment system.