Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: "Commons HttpClient Project"
 <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: DO NOT REPLY [Bug 24560]  -  HttpClient loops endlessly while
	trying to retrieve status line
From: Oleg Kalnichevski <olegk@apache.org>
Reply-To: olegk@apache.org
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
In-Reply-To: <20031117140024.8605.qmail@nagoya.betaversion.org>
References: <20031117140024.8605.qmail@nagoya.betaversion.org>
Content-Type: text/plain; charset=ISO-8859-1
Message-Id: <1069097430.4922.9.camel@localhost.localdomain>
Mime-Version: 1.0
Date: Mon, 17 Nov 2003 20:30:30 +0100
Content-Transfer-Encoding: 8bit

Odi,
That would be REALLY cool! A simple authenticating proxy (or a proxy
that could effectively 'fake' popular authentication schemes) would be a
very much appreciated contribution. By the way, have a look at the
Christian Kohlsch�tter's SimpleHttpServer:
 
http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=9066

I think that can be a good starting point for a better framework than
SimpleHttpconnection.

Oleg


On Mon, 2003-11-17 at 15:00, bugzilla@apache.org wrote:
> 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 ck@rrzn.uni-hannover.de  2003-11-17 14:00 -------
> Oleg,
> 
> thank you for reviewing my patch.
> 
> I think the reviewed version is OK in general (AFAICS from the diff - I haven't
> applied it yet). Just a few comments (new ideas?) by me:
> 
> In my opinion, "strict" mode should be very pedantic about standards compliance.
> HttpClient should notify the user wherever a problematic, non-standards
> situation is detected.
> 
> Of course, trailing whitespace should be silently ignored, but any other
> characters should be regarded as "unexpected" (is there a section in RFC 2616
> for that? I haven't found it yet).
> 
> The question is: Is (non-whitespace) garbage following the response (caused by a
> wrong Content-Length header, for example) "unexpected" enough?
> 
> In your version of the patch, there is no chance to get informed about such a
> situation - and in 'lenient' mode, the detection is disabled completely (did you
> check the TestBadContentLength testcase? does it pass?).
> 
> Regarding the ProtocolException/ResponseConsumedWatcher thing, of course, it
> _is_ a workaround to get that Exception thrown to the caller. However, I would
> appreciate it if the user _would_ receive that Exception (somehow).
> 
> I even think it is not such a bad idea to keep that in responseConsumed(), just
> to inform every HttpClient component that there was an error while reading the
> response (the interface is not public, anyway). Instead of throwing an
> Exception, we could also have a boolean "without/with errors" return value, of
> course...
> 
> In short, I would prefer the following behaviour:
> 
> - For any mode: If garbage is detected, read (up to a certain limit of bytes
> "N") until end of garbage (maximum of N bytes) or until a non-whitespace
> character is received; N is something < 10 (should be user-definable).
> 
> - For any mode, close the connection (the conncetion is definitely unreliable).
> 
> - For strict mode, throw a ProtocolException if anything else but whitespace has
> been received.
> 
> - (Optionally) introduce an extra "pedantic" mode (inherits strict mode) and
> throw a ProtocolException even if N bytes of _whitespace_ garbage have been
> received.
> 
> 
> Best regards,
> 
> Christian
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org