Am Freitag, 10. Oktober 2003 18:56 schrieb Eric Johnson: > (...) If we took > your suggestion and simply stopped reading the stream sent by the > server, when processing the _next_ request on the same socket, we'd run > into lots of problems.
Eric, I think this is the problem of my workaround, which I now understand. You will agree that it would be better to throw an IOException (EOFException) in case of unexpected EOFs (from the view of HTTPClient.class) instead of just returning a "regular EOF" (-1). I have modified my solution to do so. Before sending a patch, I will try to explain my idea. As far as I understand, in HttpMethodBase.readResponseBody, an AutoCloseInputStream is created, which wraps around the inner InputStreams (ChunkedInputStream, eventually LimitSizeInputStream and SocketInputStream). The AutoCloseInputStream calls a ResponseConsumedWatcher defined in HttpMethodBase itself - right after the stream was consumed to be able to reuse the connection. In case that LimitSizeInputStream throws an EOFException because the limit is reached, this EOFException will be thrown up to the AutoCloseInputStream. Instead of just throwing it again, a "readErrors" flag is set and thrown right after that to the caller. When notifyWatcher() is called next time, it will call watcher.responseConsumed with readErrors as parameter. HTTPMethod's ResponseConsumedWatcher then calls responseBodyConsumed(readErrors), where we now can decide whether to close the underlying Connection or release it for further processing. If readErrors == true, then the connection will definitely be closed. Would you accept such a solution? Christian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
