FULL PRODUCT VERSION :
ADDITIONAL OS VERSION INFORMATION :
All operating systems
A DESCRIPTION OF THE PROBLEM :
Prior to Java 6, webstart would check for updates by sending a HEAD request
to get the timestamp of the resources that make up the application. These resources include the jnlp file and the jar files. If the timestamp of the resource on the web server is newer than the timestamp of its counterpart on the client, webstart would send a GET request to fetch the resource from the web server.
The HEAD request was processed by the web server while the GET request was processed by the JnlpDownloadServlet.
This changed in Java 6. Instead of sending HEAD requests to get the timstamp, webstart now sends GET requests with an "if-modified-since" header variable. This header variable instructs the web server to return the resource only if its timestamp is newer than the variable's timestamp value. This means that only GET requests are now sent with all requests handled by the JnlpDownloadServlet.
The current version of the JnlpDownloadServlet ignores the "if-modified-since"
header variable and processes the GET request by simply returning the resource as it always has. This means that all resources will be downloaded each time the application is launched.
A few changes to the servlet are required to handle the possible inclusion of
the "if-modified-since" header variable. It should work with both Java 6 and earlier versions.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Try any webstart app that uses the JnlpDownloadServlet to return the jnlp file and jar files or packed jar files. Webstart 5 works as expected. Webstart 6 will download the resources each time.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JnlpDownloadServlet should handle the "if-modified-since" header variable and return a standard 304 type response if unmodified.
ACTUAL -
jar resources are downloaded each time instead of only those that have been modified.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
A few changes will fix the problem.
DownloadRequest.java
Added a class variable to hold the value of "if-modified-since" if it is present in the request.
DownloadResponse.java
Added a method to return a HttpServletResponse.SC_NOT_MODIFIED (304) response.
JnlpDownloadServlet.java
In constructResponse(), compare request's timestamp with resource's. If same, return a 304 response.
For older versions of webstart, the timestamps will never be equal so execution will continue as per normal.