FULL PRODUCT VERSION :


A DESCRIPTION OF THE PROBLEM :
When the WebServer responds to the GET commands and provides the 'Expires' HTTP field with a FUTURE date, this makes WebStart cache this information and NOT CHECK for file modifications online until the Expires date is reached, even when running the app in "online" mode.

Many WebServers and Proxys return future 'Expires' dates for files (including JAR files, JNLPs, PNGs), like one day or so greater than the request timestamp.

When this happens, my guess is that when you lauch the app again, WebStart is comparing this Expires date with the current date, and if the current date is less than the Expires date, it is ALWAYS using the cached file and NEVER checks online until that date is reached.

Many many people are reporting problems related to WebStart always using the cached files and never checking online. I believe this is the cause.

WebStart should not trust the 'Expires' field returned from the HTTP response when it runs in ONLINE mode. In that case, it should always check for the LastModified date.

The WebServer I use is always returning one day in the future for the Expires date, and I can always reproduce this bug. After the first time the app runs, no matter which files I modify on the server, the WebStart client never checks for modifications until that one day passes.





REPRODUCIBILITY :
This bug can be reproduced always.