FULL PRODUCT VERSION :
java version  " 1.7.0_17 " 
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) Client VM (build 23.7-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 5.2.3790]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Java caching turned on.

A DESCRIPTION OF THE PROBLEM :
When Java caching is on, the HTTP GET request issued by the JRE as a result of loading an applet includes a content-type.

The content-type is only valid in a POST or PUT. This means the GET request is invalid HTTP.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Java caching is on.
With appropriate TCP capture, navigate to http://java.com/en/download/testjava.jsp

Or any convenient applet.

Note: using both Chrome and Firefox exhibited this.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No content-type in the GET request header.
ACTUAL -
GET http://java.com/applet/TestJava/lib/LatestJavaVersionXMLParser.jar HTTP/1.1
accept-encoding: pack200-gzip, gzip
content-type: application/x-java-archive
User-Agent: Mozilla/4.0 (Windows 2003 5.2) Java/1.7.0_17
Host: java.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Proxy-Connection: Keep-Alive
Cookie: s_nr=1363660159884; JSESSIONID=5D5C69152501E14D47DA4BEEA37124E7; s_cc=true; gpName=javac%3ASupport%3AHelp%3Atestvm.xml; gpChannel=javac%3ASupport%3AHelp; gpServer=java.com; s_sq=%5B%5BB%5D%5D


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
This is a big issue for us as we deploy externally accessible applets which are hosted behind HTTP filter and firewall. Invalid HTTP requests simply result in an error page being returned to the client.
We are deploying configuration changes for a work around, which requires signoff from our security team. It may seem minor, but in our large organisation it has the potential to derail deployment of a Java solution, and has increased the noise about reliability and security of Java technology.

Hopefully the configuration changes will be approved but we are looking at a deployment delay of about a month.

The same issue occurs on Mac platform. Also that with 64 bit JRE there is the same impact on our site (we currently have to advise clients running OSX 10.7 and above to turn caching off), but with 32 bit JRE it seems to retry the GET requests with different headers, finally working after three attempts with a valid GET (no content-type in header).