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: [email protected] For additional commands, e-mail: [email protected]
