JDK-6424590 : Failure to handle HTTP/1.1 chunked responses with no Content-Length header set
  • 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: 2006-05-11
  • Updated: 2011-02-16
  • Resolved: 2006-12-08
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
1.5.0_06-b05

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

EXTRA RELEVANT SYSTEM CONFIGURATION :
Java running as applet in either Internet Explorer and Mozilla browsers, connecting to Apache Tomcat via an AJP13 connecter from Apache HTTP Server.

A DESCRIPTION OF THE PROBLEM :
Java is sometimes unable to process the content of a chunked HTTP/1.1 response. This occurs when ALL of the following conditions occur:

- An HttpURLConnection is created from code running in an applet within a browser.
- The response uses chunked Transfer-Encoding
- The content is obtained using getErrorStream() (ie the response code != 200)
- There is no Content-Length header parameter set

In this specific case, all header information can be obtained correctly, but the getErrorStream method returns an InputStream containing no data.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Set up Apache Tomcat, using an AJP13 connection through Apache Webserver on port 80.

Create a java applet that makes an HTTP connection to a servlet. The applet should use getErrorStream for non-200 response codes, and should attempt to read data from the InputStream that getErrorStream() returns.

The servlet that the applet connects to should return a non-200 response code, as well as some meaningful data.

Create a holding page for the applet, so that it can be accessed in a browser.

Deploy everything to the Tomcat container. Connect a browser to the applet's holding page so the applet loads.

Ensure that the HTTP response from the server uses HTTP/1.1 chunked Transfer-Encoding, with no Content-Length header specified.

The applet will attempt to connect to the servlet, which should return a non-200 response code. When the applet attempts to call getErrorStream, an InputStream will be returned that contains no data.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The InputStream obtained from the getErrorStream() method should contain the meaningful data provided by the servlet.
ACTUAL -
The InputStream obtained from the getErrorStream() method contains 0 bytes of data.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
            // Note this code should be contained within an applet, and
            // requires a connection to a server.

            URL url = new URL(addressToConnectTo);

            HttpURLConnection c = (HttpURLConnection)url.openConnection();
            c.setConnectTimeout(timeout);
            c.connect();
            /* Check if we are getting normal or error stream.
             * Error stream will be returned if response is a Fault. */
            if(c.getResponseCode() != c.HTTP_OK) {
                input = new BufferedInputStream(c.getErrorStream());
            } else {
                input = new BufferedInputStream(c.getInputStream());
            }
            
            /* Convert response to byte array and return */
            ByteArrayOutputStream os = new ByteArrayOutputStream();
            byte[] buffer = new byte[512];
            int numRead = 0;
             
            while((numRead = input.read(buffer) ) != -1) {
                os.write(buffer, 0, numRead);
            }

            input.close();

            System.out.println(os.size());

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
A workaround for this was developed by forcing Apache to downgrade the request to HTTP/1.0 to prevent chunking, with the command:

BrowserMatch "Java" downgrade-1.0 force-response-1.0

Comments
EVALUATION Confirmed with the submitter that the server is sending a "Connection: close" header. This is a duplicate of 6488669.
08-12-2006

EVALUATION Looks like it might be a duplicate of 6488669. More information about the response headers requested from the submitter.
08-12-2006