[
https://issues.apache.org/jira/browse/CXF-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13764565#comment-13764565
]
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:
{code}
public static void main(String[] args) throws Exception {
URL testServer = new URL("http://localhost:9005/raw/customers";);
HttpURLConnection connection = (HttpURLConnection) testServer
.openConnection();
// connection.setChunkedStreamingMode(0);
connection.setDoOutput(true);
OutputStreamWriter out = new OutputStreamWriter(
connection.getOutputStream());
out.write("hello!");
out.close();
BufferedReader in = null;
try {
in = new BufferedReader(new InputStreamReader(
connection.getInputStream()));
String response;
while ((response = in.readLine()) != null) {
System.out.println(response);
}
} catch (Exception e) {
BufferedReader errorIn = null;
try {
errorIn = new BufferedReader(new InputStreamReader(
connection.getErrorStream()));
String response;
while ((response = errorIn.readLine()) != null) {
System.out.println("ERROR: " + response);
}
} finally {
if (errorIn != null)
errorIn.close();
}
} finally {
if (in != null)
in.close();
}
}
{code}
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:
{quote}
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.
{quote}
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 response.
thanks,
Jesse
> WebClient using POST with chunking enabled (the default) can't read 401 error
> response stream
> ---------------------------------------------------------------------------------------------
>
> Key: CXF-5267
> URL: https://issues.apache.org/jira/browse/CXF-5267
> 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.):
> {code:title=TestWSClient.java|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(), e);
> }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: http://www.atlassian.com/software/jira
