hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line
Date Tue, 09 Dec 2003 17:46:24 GMT
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 olegk@apache.org  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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message