Return-Path: Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@www.apache.org Received: (qmail 25477 invoked from network); 10 Dec 2003 13:08:41 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 10 Dec 2003 13:08:41 -0000 Received: (qmail 6136 invoked by uid 500); 10 Dec 2003 13:08:37 -0000 Delivered-To: apmail-jakarta-commons-httpclient-dev-archive@jakarta.apache.org Received: (qmail 6106 invoked by uid 500); 10 Dec 2003 13:08:37 -0000 Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Commons HttpClient Project" Reply-To: "Commons HttpClient Project" Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 6024 invoked from network); 10 Dec 2003 13:08:36 -0000 Received: from unknown (HELO exchange.sun.com) (192.18.33.10) by daedalus.apache.org with SMTP; 10 Dec 2003 13:08:36 -0000 Received: (qmail 283 invoked by uid 50); 10 Dec 2003 13:08:49 -0000 Date: 10 Dec 2003 13:08:49 -0000 Message-ID: <20031210130849.282.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-httpclient-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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 ck@rrzn.uni-hannover.de 2003-12-10 13:08 ------- Oleg, in fact, this checked exception is caught and simply logged with LOG.error (see patched HttpMethodBase.responseBodyConsumed()). A simple solution would to be to remove this LOG.error(...) statement (just as in closeSocketAndStreams) - at least if WARN_EXTRA_INPUT is false If you really wish that this potential IOException will not be triggered at all, I suggest an option to have the already discussed TEST_EXTRA_INPUT modes "disabled"/"enabled and silent"/"enabled with logging". Christian --------------------------------------------------------------------- To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org