FULL PRODUCT VERSION :
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Applies to all network configurations, including the simplest configuration with Web Start Client and Apache/Tomcat installed on same Windows box.

A DESCRIPTION OF THE PROBLEM :
The Web Start client fails to check for updated JNLP files, making it impossible to ensure that users have pulled down the latest update to an existing Web Start application. This means that some users might continue to use an unpatched application with known defects for an indefinite period after the defects have been corrected and made available.

This problem occurs when launching a Web Start application from an existing Web Start shortcut. This problem does not occur when launching from a browser, but we have no way to prevent users from using existing web start shortcuts instead of the browser. This problem occurs for certain configuration options associated with the new JNLP "update" element. It occurs if the "check" attribute is set to "Always" or "Timeout". It also occurs if the element is not defined, since the web start client defaults the setting to check=Timeout, policy=always, when update is not defined.

Contrary to the document "Java Web Start enhancements in version 6", it appears that the "Expires" header has no effect. The "cache-control: no-cache" header was not evaluated, since IE 6 and IE 7 will not launch a web start app if this header is associated with the JNLP file. Other headers such as "pragma no-cache" and "cache-control must-revalidate" also have no effect on this problem. Even if one of these headers did have a beneficial effect, it would be too late to take advantage of that for the thousands of users who have installed Java 6 and used the Java 6 web start client to download their Java 5 web start application, since those users are now in a situation where their web start client will never check for an updated JNLP file and so will not associate any new headers with the cached JNLP.


REGRESSION. Last worked in version 5.0

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Use the JNLPDownloadServlet that is provided with the JDK, any convenient "HelloWorld" kind of test application packaged in a file named "application.jar", and a JNLP file similar to the example JNLP file below.

2) Enable logging on the web server or in the JNLP download servlet in order to log all requests from the web start client for the JNLP file.

3) Launch the application once from an IE browser and verify that it downloads correctly. Allow it to install a shortcut on the Windows Start menu.

4) Close the application and then try to launch it again, but this time launch it from the Start menu shortcut. Note that the web start client does not make any new request for the JNLP file. If you update the JNLP to reference new Jar files, associated new parameters, or reference new GIF files, none of these changes will propagate to the end user unless they go back to the browser to launch the application.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The web start client should always check for an updated JNLP file every time the application is launched, regardless of how it is launched and regardless of which attributes are associated with JNLP "update" element, but especially when the "check" attribute has a value of "always".
ACTUAL -
For combinations of <update check="always" policy="always" /> or <update check="timeout", policy="always">, the Web Start client will never check for an updated JNLP file if the user launches from a start menu shortcut.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error messages are associated with this behavior.

My JNLPDownloadServlet log for the first launch (from the browser) included the following lines:

JnlpDownloadServlet(4): Initializing
JnlpDownloadServlet(3): Request: /pjserv/servlet/JnlpDownloadServlet/HelloWorld.jnlp
JnlpDownloadServlet(3): User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8)
JnlpDownloadServlet(4): DownloadRequest[path=/servlet/JnlpDownloadServlet/HelloWorld.jnlp encoding=gzip, deflate isPlatformRequest=false]
JnlpDownloadServlet(4): Basic Protocol lookup
JnlpDownloadServlet(4): JnlpResource: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/HelloWorld.jnlp lastModified=Thu Jun 09 16:42:45 EDT 2011]]
JnlpDownloadServlet(3): Resource returned: /servlet/JnlpDownloadServlet/HelloWorld.jnlp
JnlpDownloadServlet(4): SupportQuery in Href: false
JnlpDownloadServlet(4): lastModified: 1307652165218 Thu Jun 09 16:42:45 EDT 2011
JnlpDownloadServlet(3): Request: /pjserv/servlet/JnlpDownloadServlet/HelloWorld.jnlp
JnlpDownloadServlet(3): User-Agent: JNLP/6.0 javaws/1.6.0_22 (b04) Java/1.6.0_22
JnlpDownloadServlet(4): DownloadRequest[path=/servlet/JnlpDownloadServlet/HelloWorld.jnlp encoding=gzip isPlatformRequest=false]
JnlpDownloadServlet(4): Basic Protocol lookup
JnlpDownloadServlet(4): JnlpResource: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/HelloWorld.jnlp lastModified=Thu Jun 09 16:42:45 EDT 2011]]
JnlpDownloadServlet(3): Resource returned: /servlet/JnlpDownloadServlet/HelloWorld.jnlp
JnlpDownloadServlet(4): SupportQuery in Href: true
JnlpDownloadServlet(4): lastModified: 1307652165218 Thu Jun 09 16:42:45 EDT 2011
JnlpDownloadServlet(3): Request: /pjserv/servlet/JnlpDownloadServlet/application.jar?version-id=1.0
JnlpDownloadServlet(3): User-Agent: JNLP/6.0 javaws/1.6.0_22 (b04) Java/1.6.0_22
JnlpDownloadServlet(4): DownloadRequest[path=/servlet/JnlpDownloadServlet/application.jar encoding=pack200-gzip,gzip query=version-id=1.0 version=1.0 isPlatformRequest=false]
JnlpDownloadServlet(4): Version-based/Extension based lookup
JnlpDownloadServlet(3): Rescanning directory: /servlet/JnlpDownloadServlet/
JnlpDownloadServlet(4): File directory: J:\ws\100a\indus\portalj\servlet\JnlpDownloadServlet
JnlpDownloadServlet(4): Read resource: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/application.jar versionId=1.0 name=application.jar lastModified=Thu Jun 09 12:59:43 EDT 2011] returnVersionId=1.0]
JnlpDownloadServlet(4): JnlpResource: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/application.jar versionId=1.0 name=application.jar lastModified=Thu Jun 09 12:59:43 EDT 2011] returnVersionId=1.0]
JnlpDownloadServlet(3): Resource returned: /servlet/JnlpDownloadServlet/application.jar
JnlpDownloadServlet(4): Real resource returned: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/application.jar versionId=1.0 name=application.jar lastModified=Thu Jun 09 12:59:43 EDT 2011] returnVersionId=1.0]
JnlpDownloadServlet(3): Request: /pjserv/servlet/JnlpDownloadServlet/images/hwjnlpicon.gif
JnlpDownloadServlet(3): User-Agent: JNLP/6.0 javaws/1.6.0_22 (b04) Java/1.6.0_22
JnlpDownloadServlet(4): DownloadRequest[path=/servlet/JnlpDownloadServlet/images/hwjnlpicon.gif encoding=gzip isPlatformRequest=false]
JnlpDownloadServlet(4): Basic Protocol lookup
JnlpDownloadServlet(4): JnlpResource: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/images/hwjnlpicon.gif lastModified=Fri May 18 09:28:14 EDT 2007]]
JnlpDownloadServlet(3): Resource returned: /servlet/JnlpDownloadServlet/images/hwjnlpicon.gif
JnlpDownloadServlet(4): Real resource returned: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/images/hwjnlpicon.gif lastModified=Fri May 18 09:28:14 EDT 2007]]

After successfully populating the cache and creating the start menu shortcut, I tried launching from the start menu shortcut, and the JNLPDownloadServlet's log showed these lines:

JnlpDownloadServlet(3): Request: /pjserv/servlet/JnlpDownloadServlet/images/hwjnlpicon.gif
JnlpDownloadServlet(3): User-Agent: JNLP/6.0 javaws/1.6.0_22 (b04) Java/1.6.0_22
JnlpDownloadServlet(4): DownloadRequest[path=/servlet/JnlpDownloadServlet/images/hwjnlpicon.gif encoding=gzip isPlatformRequest=false]
JnlpDownloadServlet(4): Basic Protocol lookup
JnlpDownloadServlet(4): JnlpResource: JnlpResource[WAR Path: /servlet/JnlpDownloadServlet/images/hwjnlpicon.gif lastModified=Fri May 18 09:28:14 EDT 2007]]
JnlpDownloadServlet(3): Resource returned: /servlet/JnlpDownloadServlet/images/hwjnlpicon.gif
JnlpDownloadServlet(4): return 304 Not modified

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
This is the JNLP file that I used with the JNLPDownloadServlet

<?xml version="1.0" encoding="UTF-8"?>
<jnlp codebase="$$codebase" href="HelloWorld.jnlp" >
<information>
<title>Hello World</title>
<vendor>Myself</vendor>
<description>just an example</description>
<icon href="images/hwjnlpicon.gif"/>
<shortcut online="true">
<menu submenu="Myself"/>
</shortcut>

</information>
<update check="always" policy="always"/>
<resources>
<j2se version="1.2+"/>
<jar href="application.jar" version="1.0" />
</resources>
<application-desc/>
</jnlp>
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Two workarounds exist, but these require the user to realize that there is a problem and take appropriate steps. No workarounds exist from the perspective of an administrator who wants to enforce a requirement for all users to take an update immediately.

End users who elect to receive an update can use either of these methods.
1) Launch with the browser
2) Use javaws commandline to remove the app from the cache and then reinstall it.