DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560 HttpClient loops endlessly while trying to retrieve status line ------- Additional Comments From [EMAIL PROTECTED] 2003-12-09 17:46 ------- Christian, Well, I have some bad news. I was working on merging TestBadContentLength patch with the main one (Patch (take 6)) in order to get it prepared to be checked in into CVS trunk. When I reran the tests, I unfortunately discovered that several I/O exception were thrown that were not there before. Aparently those exceptions have been caused by the newer Tomcat (version 4.1.29) which appears to be dropping connection immediately after having sent the response body if the 'connection: close' request header is present in the request. So what is happening is that HttpConnection.isResponseAvailable results in an I/O exception, as the socket is closed on the server side the same moment the last response byte was sent: [ERROR] HttpMethodBase - -Unexpected I/O error when testing for extra response data <java.io.IOException: Stream closed>java.io.IOException: Stream closed at java.io.PushbackInputStream.ensureOpen(PushbackInputStream.java, Compiled Code) at java.io.PushbackInputStream.available(PushbackInputStream.java:238) at org.apache.commons.httpclient.HttpConnection.isResponseAvailable(HttpConnection.java:863) at org.apache.commons.httpclient.HttpMethodBase.responseBodyConsumed(HttpMethodBase.java:2263) at org.apache.commons.httpclient.HttpMethodBase$1.responseConsumed(HttpMethodBase.java:1765) at org.apache.commons.httpclient.AutoCloseInputStream.notifyWatcher(AutoCloseInputStream.java, Compiled Code) at org.apache.commons.httpclient.AutoCloseInputStream.checkClose(AutoCloseInputStream.java, Compiled Code) at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java, Compiled Code) at java.io.FilterInputStream.read(FilterInputStream.java:90) at org.apache.commons.httpclient.AutoCloseInputStream.read(AutoCloseInputStream.java:161) at org.apache.commons.httpclient.HttpMethodBase.getResponseBody(HttpMethodBase.java, Compiled Code) at org.apache.commons.httpclient.HttpMethodBase.getResponseBodyAsString(HttpMethodBase.java:740) at org.apache.commons.httpclient.TestMethodsLocalHost.testMethodsGet(TestMethodsLocalHost.java:174) This is of course a fringe case, but the whole idea of having HttpConnection.isResponseAvailable was to make HttpClient more reliable, and not less reliable. We clearly overlooked this scenario. In Java prior to version 1.4 there is no way to test if the socket has been closed on the other side, so using Socket#isClosed is not an option. I am afraid HttpMethodParams.WARN_EXTRA_INPUT stuff must be completely removed. The offending code needs to be removed, and the whole process will have to start from the very start. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
