Michael Becke wrote: [snip]
I spent quite a while crawling over this part of the code, and it seems to me that if you don't have a content length or chunked encoding on the response, the RFC indicates that the only way for the client to detect the end of the content on the response is to actually close the socket. In the case where the "AutoCloseInputStream" wraps the raw socket, the raw socket should be closed, because the server is going to close it anyway.
I've been looking into this a little more and I'm actually not sure if AutoCloseInputStream should close the stream or not. I vaguely remember when this was first written and the various interactions are quite complex. In most cases the AutoCloseInputStream is not wrapping the actual socket stream. Usually there is another stream in the middle, either a ContentLengthInputStream or ChunkedInputStream. Both of which do not close the socket stream. The only case a socket input stream will be closed is when there is no chunking or content length. For this case it is difficult to determine when the response content is complete and therefore when it can be reused. In this case it might actually be reasonable to close the socket stream and force a reconnect. What does everyone think?
I went over this code carefully to try to insure that calling "close" on the getResponseBodyAsStream() result would _always_ be safe. As a result, there is a fairly intricate dance between the stream wrapper, the method, and the connection manager, so that they all stay in sync with each other, and the appropriate amount of data from a persistent connection will be read, rather than attempting to "scan" to find the next occurrence of "HTTP/1.1" in the byte stream.
-Eric.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
