More details below...
I just don't get why the behaviour should be different. My perspective on this is from a users view of the client and form that perspective it doesn't make sense for the different behaviour and the resulting undocumented side effects when running on MS Sucky Sockets (TM).
Yes getResponseBody() reads the whole response using a local buffer. But I can do the same using getResponseAsStream and my code would be almost identical to getResponseBody barring the call to setResponseStream(null); and yet still, in one case a socket connection would be lost.
That's just it, there is no difference. The call setResponseStream(null) has no effect, it is just there to be ultra thorough. HttpMethodBase.responseBodyConsumed() will be called immediately after the response body is read. This will happen if it is read from inside or outside HttpMethodBase. It is based on the socket stream.
There is no correlation to the socket being lost and reading the response. It is solely because the connection is left open as per the HTTP spec <http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1> and that a reference to the connection is lost.
If I take your argument, then it is logical to conclude that getResponseAsStream is incorrectly allowing the socket to be released via releaseConnection and thus not allowing the efficiencies of the keep-alive mechanism.
The connection is released back to the HttpConnectionManager and it is then up to the connection manger to do something with it. The intention is that an instance of HttpClient or HttpConnectionManager will be used to execute multiple methods, therefore allowing connection reuse.
As I originally said and demonstrated I can work around this by using getResponseAsStream, or switch OS's but...
The only difference would be if you are calling close() on the stream returned from getResponseAsStream() this could in some special circumstances close the connection. As per my previous email you can fix this by reusing the HttpClient/HttpConnectionManager, setting the header "Connection: close", or by implementing a new type of connection manager. All of these should be easier than switching to a new OS:)
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
