JDK-6563305 : setRequestProperty does not work for HttpURLConnection in applet when cached
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-05-30
  • Updated: 2013-01-10
  • Resolved: 2008-06-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u10 b26Fixed 7Fixed
Description
FULL PRODUCT VERSION :
java version "1.6.0_01"
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

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

A DESCRIPTION OF THE PROBLEM :
Our applet running under 1.5 is a signed applet that connects to IP
video cameras and uses basic authentication for userid password. The
IP video cameras are basically http 1.0 web servers where you load a
particular URL you will get back a JPEG. With the recent autoupdate to
1.6 our applet no longer works. We have included a test case of code
with a header dump of the TCPIP traffic under both 1.5 and 1.6. Please
review the code and the HTTP session. The problem is that under 1.6
calls to the class HttpURLConnection  and method setRequestProperty
are not being honored. This is required to set the userid and password
for basic authentication. This is very clear in the TCP output
included in the orginal post. We have also identified that if you go
to the Java 1.6 control panel and select Temporary Internet
Files-Settings and uncheck Keep Temporary files on my computer then
our applet will work under 1.6. The difference is probably in the
class loader used to set security when the applet is downloaded versus
the class loader that load the file from local cache and the
appropriate security policy. This is not an acceptable solution as we
need the ability to cache applets or have a one time download.
 
We do not get any security exceptions or errors in the console from
the java runtime.
 
We are currently testing setting different policies for the .Net
permissions which may be required under 1.6 to add to the HTTP Header.
This is either a security hole in 1.5 that is now fixed in 1.6 or a
bug in the security manager under 1.6. Either way we need guidance on
exactly what 1.6 is expecting regarding security for application code
to set the HTTP header in a signed applet and why the behavior is
different when cached or not-cached.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Steps can be followed in sample code for the applet.

This bug is now occurring at our customer locations based on the auto-update from 1.5 to 1.6


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
You should be able to set the request property for basic authentication in a signed applet. In the actual results the TCP transactions were captured for Java 1.5 applet where it works, Java 1.6 applet where it doesn't work and a Java 1.6 application where it does work.

If you turn off caching for applets in Java control panel then the Java 1.6 applet works. This is probably a problem with the security manager is different if the jar is loaded from a web server versus loaded from local cache


ACTUAL -
HTTP Requset/Response running as an applet by using jre 1.5.0_10
GET /jpg/1/image.jpg? HTTP/1.1
Content-Type: image/jpeg
Authorization: Basic cm9vdDpzcDEy
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_10
Host: 127.0.0.1:9900
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: image/jpeg
Content-Length: 46142

HTTP Requset/Response running as an applet by using jre 1.6.0_01
GET /jpg/1/image.jpg? HTTP/1.1
accept-encoding: gzip
Host: 127.0.0.1:9900
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_01
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

HTTP/1.1 401 Unauthorized
Date: Tue, 08 May 2007 15:30:04 GMT
Accept-Ranges: bytes
Connection: close
WWW-Authenticate: Basic realm="/"
Content-Type: text/html; charset=ISO-8859-1

<HTML><HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
<BODY><H1>401 Unauthorized</H1>
Your client does not have permission to get URL /jpg/1/image.jpg from this server.
</BODY></HTML>

HTTP Requset/Response running as a java application using 1.6
GET /jpg/1/image.jpg? HTTP/1.1
Content-Type: image/jpeg
Authorization: Basic cm9vdDpzcDEy
User-Agent: Java/1.6.0_01
Host: 127.0.0.1:9900
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

HTTP/1.0 200 OK
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Connection: close
Content-Type: image/jpeg
Content-Length: 45869
  



ERROR MESSAGES/STACK TRACES THAT OCCUR :
No crash and no exceptions from security manager. The error is silent. The output in the actual results shows the header information is not set in 1.6 applet

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Source code example for a signed applet

package com.vp;

 import java.awt.Container;
 import javax.swing.JDesktopPane;

 import java.net.HttpURLConnection;
 import java.net.URL;

 import org.apache.commons.codec.binary.Base64;

 public class SimpleTest extends javax.swing.JApplet {
     public SimpleTest() {}
    
     public void init() {
         try {
             String strUrl =  "http://192.168.200.31/jpg/1/image.jpg?";
             URL urlConn = new URL(strUrl);
             HttpURLConnection huc = (HttpURLConnection)urlConn.openConnection();
            
             String admin = "root";
             String password = "sp12";
             huc.setRequestProperty("Content-Type", "image/jpeg");
             huc.setRequestProperty("Authorization", getBasic(admin, password));
             huc.setRequestMethod("GET");
             huc.setDoInput(true);
            
             // get response
             System.out.println("response code: " + huc.getResponseCode());
             System.out.println("response message: " + huc.getResponseMessage());
             System.out.println("content type: " + huc.getContentType());
         } catch (Exception e) {
             e.printStackTrace();
         }
     }
        
     public void start() {
         System.out.println("Starting image applet...");
     }
    
     public void stop() {
         System.out.println("Stopping image applet...");
     }
        
     private String getBasic(String user, String password) {
         String authBasic = "Basic ";
         try {
             String userpass = user + ":" + password;
             byte[] encoding = Base64.encodeBase64(userpass.getBytes("ISO-8859-1"));
             authBasic += new String(encoding, 0, encoding.length, "US-ASCII");
         } catch(Exception e) {
             e.printStackTrace();
         }
         return authBasic;
     }

     public static void main(String[] arg) {
         new SimpleTest().init();
     }
 }
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Setting in Java control panel to disable caching of applets as temporary internet files.

Release Regression From : 5.0u11
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION the problem is because we are making a update check request in get(final URI uri, String rqstMethod, Map requestHeaders), and we didn't pass in the requestHeader from get. so if we use the requestHeader value when we make the update check request, the customer problem should be fixed.
20-05-2008

EVALUATION Problem is in the caching mechanism in the plugin. Since jdk6, the plugin caches all resources, and the way it uses the caching API, causes this problem. More detailed evaluation will follow
08-08-2007

EVALUATION I have taken the sample code, and made a signed applet from it. But I can't reproduce the problem. I will contact the submitter to get another test case, but am marking bug as incomplete until then.
31-05-2007