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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
