JDK-6514485 : included JnlpDownloadServlet needs updating for use with webstart 6
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,windows_xp
  • CPU: x86
  • Submitted: 2007-01-18
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 6 JDK 7
6u2Fixed 7 b13Fixed
Related Reports
Duplicate :  
JDK-6577221 - JnlpDownloadServlet does not handle If-Modified-Since properly with jnlp files
Duplicate :  
JDK-6524054 - "update" tag causes Webstart always reporting available updates
Description
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.
Comments
EVALUATION customer testcase shows 2 problems: http://www.media-elink.com/exchange/client/exchange.jnlp 1. multiple GET requests to the same JNLP file. 2. subsequent launches will cause download window pop up with no progress bar. For 1, need more investigation to see why we make multiple GET requests to the same jnlp file. For 2, The reason why you see the download dialog is because we didn't see the 304 respond, and is entering the download code. But before we do actual download, we check the last-modified and content length against the cached entry. If it matches, it won't start the actual download. That's why there is no progress bar, and if you dig into the cache, you will see the cache entry is not modified. I agree we should update the sample servlet to handle the if-modified-since header. With that, you should probably not see the download dialog pop up anymore.
19-01-2007
EVALUATION Even though the servlet does not understand if-modified-since header that we set, our code still checks the last-modified and content-length before doing actual download. If those matches, we won't download again. And the servlet does pass back correct last-modified and content-length. I tried again and I still cannot reproduce the problem. I will contact the submitter for more information.
18-01-2007