FULL PRODUCT VERSION :
1.6.0_10 Java HotSpot(TM) Client VM

ADDITIONAL OS VERSION INFORMATION :
All OSes

A DESCRIPTION OF THE PROBLEM :
BasicService.showDocument calls DownloadEngine.isJnlpURL which makes a HEAD request to determine if the content-type indicates it's a jnlp file. We found a few problems with this:

1) If the web server doesn't return a content-type header, isJnlpURL throws an NPE due to this code:

  httpresponse.getContentType().equals("application/x-java-jnlp-file");

It should check for null.

2) With single-sign-on, the HEAD request may use up the token if the token is one-time-use resulting in the actual GET/POST request failing.

3) It seems some web servers treat the HEAD request the same as a GET resulting in unnecessary processing that may take a while.

In addtion to fixing the NPE, my suggestions are:

1) Provide an option/property to disable the isJnlpURL check.

2) Change isJnlpURL to check if the query part of the URL ends in ".jnlp" instead of issuing a HEAD request (although you may have thought of this before and there may be a problem with it).

3) remove the check altogether. The only advantage I see with it is that it launches javaws directly and avoids the extra browser window popup. But I can live with that in lieu of the potential HEAD request issues. I'm sure others (that are aware of it) can live without it too judging from previous bug reports (6565562 , 6558862).


ERROR MESSAGES/STACK TRACES THAT OCCUR :
 java.lang.NullPointerException
                at com.sun.deploy.net.DownloadEngine.isJnlpURL(Unknown Source)
                at com.sun.jnlp.BasicServiceImpl$1.run(Unknown Source)
                at java.security.AccessController.doPrivileged(Native Method)
                at com.sun.jnlp.BasicServiceImpl.showDocument(Unknown Source)


REPRODUCIBILITY :
This bug can be reproduced often.

CUSTOMER SUBMITTED WORKAROUND :
Can't use BasicService.showDocument but would like to.