FULL PRODUCT VERSION :
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) Client VM (build 11.2-b01, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Java Web Start, when downloading an application into an empty cache, uses an illegal If-Modified-Since header when requesting JAR files from a web server.  The net result is that Java Web Start applications are not properly cached by cache engines and WAN accelerators.  This causes clients to have to pull the Web Start application all the way across the WAN rather than pulling it from the local WAN accelerator or cache engine.  This bug is a dealbreaker for Java Web Start in some environments.

When a Java Web Start application initially downloads JAR files (and other resources) into the cache, the GET request includes this header:

    If-Modified-Since: Wed, 31 Dec 1969 23:59:59 GMT

which is a time_t of "-1".  Some parts of web infrastructure will refuse to properly handle this request.  For example, a Cisco WAE refuses to cache any response if the request has a malformed If-Modified-Since (IMS) header.

This bug appears to have been introduced very early in JDK6.  Java 5 Web Start downloads do not have this illegal If-Modified-Since header.  This bug still exists in openjdk 7's latest source drop as well.

  See also http://forums.sun.com/thread.jspa?threadID=5167510&start=0

The solution to this bug is below.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Clear the cache with "javaws -uninstall" and then start any Web Start application. Using wireshark or equivalent, monitor the GET requests and you will see the illegal If-Modified-Since headers.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When a file not in the cache is being downloaded into the cache, no If-Modified-Since header is expected.  Java Web Start should allow JAR files to be cached not only locally, but also at intermediate parts of the network.  This allows JWS applications to be useful across a WAN.

ACTUAL -
Due to the illegal If-Modified-Since header, cache engines and wan accelerators refuse to cache the Java Web Start application content.  That means if you have 1000 clients across a WAN, each and every client will have to go all the way across the WAN to the web server to pull all JAR files and other resources.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
HOW TO FIX THIS BUG (tested with JDK 6u2, but identical code is in 6u12):

Looking at the source to JRE6u12, in the source file deploy\src\common\share\classes\com\sun\deploy\net\DownloadEngine.java, in the method private static CacheEntry actionDownload(...), find the lines:

            long cacheEntryLastModified = -1;
            if (currentCE != null) {
                cacheEntryLastModified = currentCE.getLastModified();
            }

Change the initial value of cacheEntryLastModified from -1 to 0 and viola, the bug is fixed.  If the cache is empty, then you do not want to specify *any* If-Modified-Since time.  Setting that value to 0 will cause you to not add this header.  Setting that value to any non-zero value (positive OR negative) will cause you to generate this header.

Just to avoid confusion (and get rid of a similar "-1" initialization that is in fact immediately overwritten), earlier in this file in the method public static boolean isUpdateAvailable(...), the lines

        long cacheEntryLastModified = -1;
        
        cacheEntryLastModified = ce.getLastModified();

should probably be shortened to

        long cacheEntryLastModified = ce.getLastModified();

Any negative value for last modified is an illegal value and should be avoided.

These changes will only affect running a client when the cache is empty, so the change is pretty easy to validate.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
No full workaround exists as cache engines seem to deliberately ignore all traffic with an IMS header before 1-1-1970.  However, if the Web Start application can be loaded from a CD (or network share) in a way that it will auto-update from the web server if files change, then this will work around the issue at a cost of additional IT hours.

Release Regression From : 6.0
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.