hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line
Date Mon, 17 Nov 2003 19:30:30 GMT
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


Mime
View raw message