hc-dev mailing list archives

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


Mime
View raw message