JDK-6356776 : Incorrect http1.1 CONNECT message
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-11-30
  • Updated: 2010-05-10
  • Resolved: 2006-02-07
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
WINDOWS XP, WINDOWS 2000

EXTRA RELEVANT SYSTEM CONFIGURATION :
The plug-in sends content-length in the CONNECT message.

A DESCRIPTION OF THE PROBLEM :
If one sets the content-length in the the java code as follws:
conn.setRequestProperty("content-length", "" + toSendData.length());

The CONNECT message that is sent to the proxy contains the content-length field with the corresponding length. A CONNECT message should have content-length 0. It is in the next POST message that the content-length of the data should be placed. Some proxy server are very picky about this and refuses to set up a connection. If we do not set the content-length explicitly in the code it works fine. A fix would be to set content-length 0 in a CONNECT message.

The error is in jre 1.4 and jre 1.5

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We use Tren Micro IWSS inhouse and this one refuses to set up a connection.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
			conn.setRequestProperty("content-type", "application/x-www-form-urlencoded; charset=iso-8859-1");
			conn.setRequestProperty("content-length", "" + toSendData.length());
			

			out = new BufferedOutputStream(conn.getOutputStream());
			out.write(toSendData.getBytes("ISO-8859-1"));
			out.flush();
			out.close();
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
if we do not set content-length explicitly it works.

Comments
EVALUATION This has been fixed as a side effect of 6226610, in mustang beta. If it needs to be fixed in a previous release then an escalation will need to be filed. If we are tunneling through a proxy ( and we are in this case, SSL/TLS over proxy ), then we first send a CONNECT request to the proxy to establish the connection to the remote host and then the appropriate HTTP GET/POST/etc is sent over this connection. Before the fix for 6226610 we would send all the request headers for the second HTTP request in the CONNECT request. This was not necessary and as this bug report states could cause a problem.
07-02-2006