FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b57)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Tested against Apache and IIS servers

A DESCRIPTION OF THE PROBLEM :
Defect: Expires Header on 304 Responses

When the client has file in cache and issues a "get if modified since" request and the server responds with a 304 with an updated expires time header, the expires time in the cache is not updated. This causes unneccessary round trips to the server when the expires tag has told the client it is unneccessary. Most browsers handle a 304 by still updating cache using headers.

In our enterprise, we expire content at midnight so software updates can be pushed overnight. On the second day after a deployment, applets requesting gifs not in jar files make "get if modified since" requests on every load even if the first request resulted in an updated EXPIRES header on the cached version. This comes into play when we have poorly packaged third party applets. The new download engine in mustang, which still may be under construction, is supposed to cache all contents and we had been looking to that as a solution to the deployment issues with have with some software vendors. However, if the expires time isn't set to what the server instructs, we still end up with runtime performance issues based on deployment considerations.


For another description see, http://www.apacheweek.com/issues/96-08-30
<quote>
Expires Header on 304 Responses
When a browser has a file in its cache, it does not bother getting it from the server unless it has changed. It does this by sending a conditional request, telling the server to only send the data if it has been modified since the time that the browser last obtained it. If it has not changed on the server, the server responds with a 304 status, meaning "use local copy".

Responses can also contain a definite time when the document will expire, in the Expires HTTP header. There are some cases where the expiry time of a document might change, even if the document itself has not changed. So a 304 status message can include an updated expires time, which the browser should use to replace the expires time in it's cached copy of the file. Currently Apache does not send out the expires header on 304 status, which is required by HTTP/1.1. The problem with not sending out the expires header is that the browser still keeps the old expiry time, so it thinks the document has expired straight away. This will be fixed in the next release.
<end of quote>

Currently response codes 200,203,206,300,301,410 cause the sun.net.www.protocol.http.HttpURLConnection class to interact with ResponseCache upon reciept of a response. The getInputStream method should also check for 304 response codes and interact with the ResponseCache.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This was reproduced on plugin 1.4.2 and 1.5.0. The class for 1.6 hasn't yet changed so we're reporting against that version.

1) Run an applet that downloads a gif file from a server that sets the expires time to current time + 24 hours.
2) Wait more than 24 hours.
3) Run the applet again.
4) Open the plugin control panel and view cache.
5) Note that the expiration time was not set to 24 hours from the most recent request.
6) Turn on a network sniffer
7) Run the applet again
8) Stop network sniffer
9) Note that get if modified since was indeed issued for the same image in cache even though expires header was sent for 24 hours from the last request.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expiration time on the object in cache should be updated.
ACTUAL -
Expiration time stayed set to expiration time sent by the first response. No scenario resulted in the expiration time ever being updated.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Package images in jars when possible.
Use IE DHTML instead of java applets.