JDK-6488669 : Bad interaction between ChunkedInputStream and HttpURLConnection$ErrorStream.getErrorStream()
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.
When the server returns an error status code while HTTP chunking is used, HttpURLConnection fails to parse the input into the error stream.
See http://forums.java.net/jive/thread.jspa?threadID=17999&start=15&tstart=0#168504 for the complete detail.
The internal implementation of the http client (sun.net.www.http.HttpClient) may incorrectly determine the keepAlive status of the connection in the case of a chunked response body, and "Connection: close" header sent from the server. This means that the ErrorStream implementation incorrectly determines that the stream is going to be kept alive but the ChunkedInputStream implementation closes it. The fix is to correctly determine the keepAlive status of the connection.
Yes, there is a bug in the HttpURLConnection implementation around how it buffers chunked ErrorStreams.
The code that does this (HttpURLConnection$ErrorStream.getErrorStream()) takes the following steps:
a) temporarily change the socket timeout
b) read from the (chunked) input stream into a buffer
c) reset the socket timeout to its original value
If the error data has been completely read then the ChunkedInputstream will call closeUnderlying(). This will try to put the connection in the keepalive cache, but may close it if there was an error or if the number of request/responses that this connection was being held open for has been exceeded. Now when we try to reset the socket timeout it will throw new SocketException("Socket is closed"). This causes getErrorStream to return null.