Return-Path: Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list commons-httpclient-dev@jakarta.apache.org Received: (qmail 4907 invoked by uid 98); 6 Dec 2002 16:14:10 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Received: (qmail 4816 invoked from network); 6 Dec 2002 16:14:06 -0000 Received: from daedalus.apache.org (HELO apache.org) (63.251.56.142) by nagoya.betaversion.org with SMTP; 6 Dec 2002 16:14:06 -0000 Received: (qmail 75363 invoked by uid 500); 6 Dec 2002 16:12:58 -0000 Received: (qmail 75356 invoked from network); 6 Dec 2002 16:12:58 -0000 Received: from unknown (HELO nose.ch) (195.134.131.71) by daedalus.apache.org with SMTP; 6 Dec 2002 16:12:58 -0000 Received: (qmail 19483 invoked from network); 6 Dec 2002 16:12:59 -0000 Received: from calvin.nose.ch (HELO nose.ch) (192.168.1.7) by 0 with SMTP; 6 Dec 2002 16:12:59 -0000 Message-ID: <3DF0CD7B.7050800@nose.ch> Date: Fri, 06 Dec 2002 17:16:59 +0100 From: =?ISO-8859-1?Q?Ortwin_Gl=FCck?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-ch, en-us MIME-Version: 1.0 To: Commons HttpClient Project Subject: Re: [PATCH] handling close properly on response input streams References: <3DEFC343.2000205@tibco.com> <3DF0B8A9.9080608@nose.ch> <3DF0C60C.8010201@tibco.com> In-Reply-To: <3DF0C60C.8010201@tibco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Eric Johnson wrote: > Ortwin, > > Thanks for try out my patch. Based on the stack traces you included, > I'm quite puzzled, and not sure how this failure is anything that my > patch could cause. I was expecting a failure (if one were to occur due > to my changes, which I hope it wouldn't) on ConnectMethod.java line 119. > Instead, the failure indicated below occurs at line 115. Only a > precious few changes in my patch, such as setting state variables, would > actually be executed by the time that the failure occurs. Line numbers might not be in sync here with your local code. Line 115 is: int code = super.execute(state, conn); > > For the moment then, I'm standing by my patch, in that I believe > (perhaps wrongly!) that the problem lies somewhere else, and that if the > problem is in my patch, that I need more information. Reading the code, > it looks like the communication is as follows: > > Client: > CONNECT / HTTP/1.1 > Various headers: various values > > (wait for HTTP/1.1 200 OK response) > (response's first line doesn't arrive, or arrives garbled, throw > recoverable exception) Well, the problem does not occur in the current CVS HEAD. So it must be your patch. I am not saying that the error occurs in your code. But the changed code makes the error happen somehow. It looks a lot like a stream is not fully read before reuse or repeating the request or alike.