Bug ID: JDK-4972238 Slow JAR file download when server doesn't return HTTP header last-modified

Versions (Unresolved/Resolved/Fixed)

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
6Resolved

Name: gm110360			Date: 12/23/2003


FULL PRODUCT VERSION :
Java Plug-in 1.4.2
Default virtual machine: 1.4.2-b28

FULL OS VERSION :
Windows 2000

EXTRA RELEVANT SYSTEM CONFIGURATION :
Internet Explorer 5.50
Server is an industrial unit embedded by a simple HTTP server

A DESCRIPTION OF THE PROBLEM :
The size of JAR file is 281kb.
Java Plug-in VM tries to load this JAR, but my server DOES NOT return the HTTP header 'last-modified' for the file, then the Plug-in retries to load the JAR file (opens the 2nd socket), leaving the first socket connection open; while the server attempts to send the whole JAR, the client's TCP window gets smaller as it receives data until the window becomes zero. (The first window size was 64kb for my PC) At this time, the server asks if the TCP window is recovered by sending 1-byte data repeatedly (the interval varies from 5 sec to 1 min). This is the cause of slow download. However, finally, the CLIENT (Plug-in VM or WinSock?) sends TCP FIN to close the connection. After this, the second socket starts to receive the JAR file (and the applet works normally).

If you disable the applet caching on the Java Plug-in control panel, this does not occur.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
(1) Close the first socket immediately when HTTP headers have
    no 'last-modified'.
(2) Or, no need to retry to download the JAR file.
    Just donwload it one time and make no caching.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Disable the applet caching, but this is not practical for users.
(Incident Review ID: 207739) 
======================================================================

EVALUATION Please provide the testcase and webserver configuration so that we can reproduce this bug here. ###@###.### 2004-01-12 I don't think the HTTP header "last-modified" has caused this problem, it probably that "keep-alive' flag is set on the webserver, please ask user trun off it in his webserver. Anyway, I do need the testcase to reproduce it here. ###@###.### 2004-01-14 The bug is in sun\plugin\cache\CachedFileLoader.java and sun\plugin\cache\CachedJarLoader.java. The caching code made a HTTP GET request to the server for downloading the file into the cache. Unfortunately, if the servers do not return "Last-Modified" or "Expires" in HTTP response headers, it would disable plugin caching for the connection, and plugin would try to redownload the file again without caching. This results in two HTTP GET requests per file. According to HTTP 1.1 spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.29), "HTTP/1.1 servers SHOULD send Last-Modified whenever feasible." This is too late to fix in Tiger, but customers could workaround the problem by configuring the server to return "Last-Modified" in the meantime. ###@###.### 2004-06-04 This should be resolved in the Unified Download Engine work. Reassign it to Thomas. ###@###.### 2004-11-10 01:30:21 GMT the check for "Last-Modified" or "Expires" is removed in the mustang plugin cache. so the resource will be cached even if these headers is missing from the server. ###@###.### 2005-06-08 22:17:27 GMT

08-06-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang

29-08-2004

Duplicate :	JDK-4802551 - Consolidate Download Engine and Cache from plugin and webstart
Duplicate :	JDK-6209058 - Jar files not cached if web server doesn't return last-modified date
Relates :	JDK-6688675 - IBM applet is very slow on JRE6 due to repeated JAR file downloads w/ no HTTP header 'last-modified'