You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Hannes Fiedler <mi...@web.de> on 2009/08/28 21:56:36 UTC
strange behaviour of getResponseBodyAsStream()
I had a strange behaviour of httpclient-3.1: When using
getResponseBodyAsStream(), my software crashed due to a IOException
caused by an attempted read-op on a closed stream, status code of the
response was okay (200). On the other hand, the exact same code worked
when i just called getResponseBodyAsString() before getting the same
again as stream (or just called getResponseBodyAsString).
Another class (written to try this https-request with httpclient) which
does essentially the same (only with hard-coded params like host,
credentials and so on, the class that actually is used is more generic)
had no problems with calling the stream-returning-method.
Can someone figure that out? I'm completely clueless ;)
That's the code of the testclass:
try {
HttpClient httpclient = new HttpClient();
httpclient.getState().setCredentials(
new AuthScope("host",443),
new UsernamePasswordCredentials("login", "password"));
PostMethod post = new PostMethod(
"https://url.de/path/toApp");
//parameters are added here via post.addParamater(key,value);
try {
int result = httpclient.executeMethod(post);
System.out.println("Response status code: " + result);
System.out.println("Response body: ");
System.out.println(post.getResponseBodyAsString());
} finally {
post.releaseConnection();
}
} catch (Exception e) {
e.printStackTrace();
}
And that the one of the clas thats actually used:
try {
url = new URL(configuration.getURL());
String host = url.getHost();
int port;
if (url.getPort() == -1) {
port = url.getDefaultPort();
} else {
port = url.getPort();
}
httpClient = new HttpClient();
httpClient.getState().setCredentials(
new AuthScope(host, port),
new UsernamePasswordCredentials(configuration
.getLogin(), configuration.getPassword()));
} catch (Exception e) {
new ErrorMessage(e);
}
post = new PostMethod(url.toString());
//adding the parameters via post.addParameter(key,value)
int httpCode=httpClient.executeMethod(post);
post.getResponseBodyAsString(); //without this call, the stream
is closed
InputStream result = post.getResponseBodyAsStream();
post.releaseConnection();
return result;
Thanks in advance
hfiedler
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: strange behaviour of getResponseBodyAsStream()
Posted by Hannes Fiedler <mi...@web.de>.
Oleg Kalnichevski wrote:
> Hannes Fiedler wrote:
>> Oleg Kalnichevski wrote:
>>> Hannes Fiedler wrote:
>>>> I had a strange behaviour of httpclient-3.1: When using
>>>> getResponseBodyAsStream(), my software crashed due to a IOException
>>>> caused by an attempted read-op on a closed stream, status code of the
>>>> response was okay (200). On the other hand, the exact same code worked
>>>> when i just called getResponseBodyAsString() before getting the same
>>>> again as stream (or just called getResponseBodyAsString).
>>>> Another class (written to try this https-request with httpclient)
>>>> which
>>>> does essentially the same (only with hard-coded params like host,
>>>> credentials and so on, the class that actually is used is more
>>>> generic)
>>>> had no problems with calling the stream-returning-method.
>>>> Can someone figure that out? I'm completely clueless ;)
>>> There is nothing strange about this behaviour.
>>> HttpMethod#releaseConnection makes sure the response content is fully
>>> consumed prior to releasing the connection back to the pool and closes
>>> the InputStream in order to prevent possible corruption of the
>>> underlying connection.
>>>
>>> HttpMethod#getResponseBodyAsString method behaves differently because
>>> it creates an in-memory copy of the response body.
>>>
>>> Consider upgrading to HttpClient 4.0.
>>>
>>> Oleg
>> So, if I got that right, calling getResponseBodyAsString() first works
>> because after that call, the response body is cached locally and
>> getResponseBodyAsStream() uses that cached response?
>
> Yes, that is the case.
>
>>
>> Are there any major changes from 3.1 to 4.0 (affecting my code)? Because
>> my time to work on this project is running out rather quickly. :(
>>
>
> That depends entirely on your code. You should seriously consider
> upgrading because HttpClient 3.1 is pretty much end of life.
>
> Oleg
I'll see what can be done in the remaining time. Anyway, thanks for your
help.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: strange behaviour of getResponseBodyAsStream()
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hannes Fiedler wrote:
> Oleg Kalnichevski wrote:
>> Hannes Fiedler wrote:
>>> I had a strange behaviour of httpclient-3.1: When using
>>> getResponseBodyAsStream(), my software crashed due to a IOException
>>> caused by an attempted read-op on a closed stream, status code of the
>>> response was okay (200). On the other hand, the exact same code worked
>>> when i just called getResponseBodyAsString() before getting the same
>>> again as stream (or just called getResponseBodyAsString).
>>> Another class (written to try this https-request with httpclient) which
>>> does essentially the same (only with hard-coded params like host,
>>> credentials and so on, the class that actually is used is more generic)
>>> had no problems with calling the stream-returning-method.
>>> Can someone figure that out? I'm completely clueless ;)
>> There is nothing strange about this behaviour.
>> HttpMethod#releaseConnection makes sure the response content is fully
>> consumed prior to releasing the connection back to the pool and closes
>> the InputStream in order to prevent possible corruption of the
>> underlying connection.
>>
>> HttpMethod#getResponseBodyAsString method behaves differently because
>> it creates an in-memory copy of the response body.
>>
>> Consider upgrading to HttpClient 4.0.
>>
>> Oleg
> So, if I got that right, calling getResponseBodyAsString() first works
> because after that call, the response body is cached locally and
> getResponseBodyAsStream() uses that cached response?
Yes, that is the case.
>
> Are there any major changes from 3.1 to 4.0 (affecting my code)? Because
> my time to work on this project is running out rather quickly. :(
>
That depends entirely on your code. You should seriously consider
upgrading because HttpClient 3.1 is pretty much end of life.
Oleg
> hfiedler
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: strange behaviour of getResponseBodyAsStream()
Posted by Hannes Fiedler <mi...@web.de>.
Oleg Kalnichevski wrote:
> Hannes Fiedler wrote:
>> I had a strange behaviour of httpclient-3.1: When using
>> getResponseBodyAsStream(), my software crashed due to a IOException
>> caused by an attempted read-op on a closed stream, status code of the
>> response was okay (200). On the other hand, the exact same code worked
>> when i just called getResponseBodyAsString() before getting the same
>> again as stream (or just called getResponseBodyAsString).
>> Another class (written to try this https-request with httpclient) which
>> does essentially the same (only with hard-coded params like host,
>> credentials and so on, the class that actually is used is more generic)
>> had no problems with calling the stream-returning-method.
>> Can someone figure that out? I'm completely clueless ;)
>
> There is nothing strange about this behaviour.
> HttpMethod#releaseConnection makes sure the response content is fully
> consumed prior to releasing the connection back to the pool and closes
> the InputStream in order to prevent possible corruption of the
> underlying connection.
>
> HttpMethod#getResponseBodyAsString method behaves differently because
> it creates an in-memory copy of the response body.
>
> Consider upgrading to HttpClient 4.0.
>
> Oleg
So, if I got that right, calling getResponseBodyAsString() first works
because after that call, the response body is cached locally and
getResponseBodyAsStream() uses that cached response?
Are there any major changes from 3.1 to 4.0 (affecting my code)? Because
my time to work on this project is running out rather quickly. :(
hfiedler
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: strange behaviour of getResponseBodyAsStream()
Posted by Oleg Kalnichevski <ol...@apache.org>.
Hannes Fiedler wrote:
> I had a strange behaviour of httpclient-3.1: When using
> getResponseBodyAsStream(), my software crashed due to a IOException
> caused by an attempted read-op on a closed stream, status code of the
> response was okay (200). On the other hand, the exact same code worked
> when i just called getResponseBodyAsString() before getting the same
> again as stream (or just called getResponseBodyAsString).
> Another class (written to try this https-request with httpclient) which
> does essentially the same (only with hard-coded params like host,
> credentials and so on, the class that actually is used is more generic)
> had no problems with calling the stream-returning-method.
> Can someone figure that out? I'm completely clueless ;)
>
> That's the code of the testclass:
> try {
> HttpClient httpclient = new HttpClient();
> httpclient.getState().setCredentials(
> new AuthScope("host",443),
> new UsernamePasswordCredentials("login", "password"));
> PostMethod post = new PostMethod(
> "https://url.de/path/toApp");
> //parameters are added here via post.addParamater(key,value);
> try {
> int result = httpclient.executeMethod(post);
> System.out.println("Response status code: " + result);
> System.out.println("Response body: ");
> System.out.println(post.getResponseBodyAsString());
> } finally {
> post.releaseConnection();
> }
> } catch (Exception e) {
> e.printStackTrace();
> }
>
> And that the one of the clas thats actually used:
> try {
> url = new URL(configuration.getURL());
> String host = url.getHost();
> int port;
> if (url.getPort() == -1) {
> port = url.getDefaultPort();
> } else {
> port = url.getPort();
> }
>
> httpClient = new HttpClient();
> httpClient.getState().setCredentials(
> new AuthScope(host, port),
> new UsernamePasswordCredentials(configuration
> .getLogin(), configuration.getPassword()));
> } catch (Exception e) {
> new ErrorMessage(e);
> }
> post = new PostMethod(url.toString());
> //adding the parameters via post.addParameter(key,value)
> int httpCode=httpClient.executeMethod(post);
> post.getResponseBodyAsString(); //without this call, the stream
> is closed
> InputStream result = post.getResponseBodyAsStream();
> post.releaseConnection();
There is nothing strange about this behaviour.
HttpMethod#releaseConnection makes sure the response content is fully
consumed prior to releasing the connection back to the pool and closes
the InputStream in order to prevent possible corruption of the
underlying connection.
HttpMethod#getResponseBodyAsString method behaves differently because it
creates an in-memory copy of the response body.
Consider upgrading to HttpClient 4.0.
Oleg
> return result;
>
> Thanks in advance
> hfiedler
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org