cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Pangburn (JIRA)" <>
Subject [jira] [Commented] (CXF-5267) WebClient using POST with chunking enabled (the default) can't read 401 error response stream
Date Wed, 11 Sep 2013 17:59:51 GMT


Jesse Pangburn commented on CXF-5267:

Hi Sergey, well I can say I'm completely surprised by this result!  That was a good question.
 I thought maybe you were wondering if the server wasn't returning the same thing in both
cases, but I had run it while watching with Wireshark and saw the exact same response.  So
NEVER would have guessed that HttpURLConnection was treating it differently.

Here's the test code I wrote to check this:
    public static void main(String[] args) throws Exception {
        URL testServer = new URL("http://localhost:9005/raw/customers");
        HttpURLConnection connection = (HttpURLConnection) testServer
        // connection.setChunkedStreamingMode(0);
        OutputStreamWriter out = new OutputStreamWriter(


        BufferedReader in = null;
        try {
            in = new BufferedReader(new InputStreamReader(
            String response;
            while ((response = in.readLine()) != null) {
        } catch (Exception e) {
            BufferedReader errorIn = null;
            try {
                errorIn = new BufferedReader(new InputStreamReader(
                String response;
                while ((response = errorIn.readLine()) != null) {
                    System.out.println("ERROR: " + response);
            } finally {
                if (errorIn != null)
        } finally {
            if (in != null)

As it stands, it's in non-chunking mode and it prints out the error stream just fine.  But
uncomment the line to turn chunking on and that error stream becomes null!

So it seems this is a problem inherent in the Java HttpURLConnection implementation that the
error response stream is lost in this case.  The API doc for that method has this:
When output streaming is enabled, authentication and redirection cannot be handled automatically.
A HttpRetryException will be thrown when reading the response if authentication or redirection
are required. This exception can be queried for the details of the error.
Not sure why they didn't make the error stream available anyway in this case (it's there on
the network, I can see it with Wireshark), but clearly the problem is upstream from CXF since
you're saying that CXF uses this internally.  So I guess nothing we can do?  It's kind of
surprising to users that flipping this request bit has anything to do with processing the

> WebClient using POST with chunking enabled (the default) can't read 401 error response
> ---------------------------------------------------------------------------------------------
>                 Key: CXF-5267
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.5.3, 2.7.5
>         Environment: Linux
>            Reporter: Jesse Pangburn
>            Priority: Minor
> If I use WebClient to POST a message to a server, then I can't read the 401 error response
stream.  If I use GET, then I can read the response stream just fine.  If I use a HTTPConduit
and disable chunking then I can read the response content just fine in all cases.
> Here's a short grid showing the tests I performed:
> ||GET/POST||chunking||return code||result||
> |GET|disabled|401|response message ok|
> |POST|disabled|401|response message ok|
> |POST|enabled (default)|401|response message BLANK!|
> |GET|enabled (default)|401|response message ok|
> |POST|enabled (default)|200|response message ok|
> Here's the code I'm using (requestStream and webClient are initialized above.  webClient
is a WebClient and requestStream is an InputStream.):
> {|borderStyle=solid}
> String requestMethod = "POST";
> InputStream responseStream = null;
> Response response = null;
> try{
> 	responseStream = webClient.invoke(requestMethod, requestStream, InputStream.class);
> } catch (Exception e){
> 	logger.log(Level.WARNING, "caught exception using webClient to call " + webClient.getCurrentURI().toString(),
> }finally{
> 	// always assign the Response object
> 	response = webClient.getResponse();
> 	// if the response entity is a LoadingByteArrayOutputStream, then we can still grab
that response content
> 	try{
> 		Object entity = response.getEntity();
> 		if (entity instanceof ByteArrayInputStream){
> 			ByteArrayInputStream bais = (ByteArrayInputStream)entity;
> 			// the stream needs to be reset before we can really use it
> 			bais.reset();
> 			responseStream = bais;
> 		}
> 	}catch (Exception e){
> 		// darn, failed to get that response entity
> 	    logger.log(Level.WARNING, "tried to get response message despite webClient exception,
but failed", e);
> 		// nothing else we can do, at least Cloverleaf will get the 500 response code and error
is in the log
> 	}
> }
> {code}
> In the failure case, when I try to read (not shown) from the response stream I get a
"-1" indicating the stream is empty.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message