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 25468] - Unchecked response header length can cause HttpClient to loop endlessly
Date Fri, 12 Dec 2003 15:47:46 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=25468>.
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=25468

Unchecked response header length can cause HttpClient to loop endlessly





------- Additional Comments From eric@tibco.com  2003-12-12 15:47 -------
I seem to recall that the chief complaint with the previous attempt to recover
from malicious servers did not attempt to deal with the particular failure
points, but rather took the approach of simply discarding the connection.  I
think the submitter also wanted the changes on the 2.0 branch.

Perhaps I can convince Oleg to be slightly less contrary to these suggested
patches?  If nothing else, I don't think we should discard the idea that some
users of HttpClient DO have to deal with malicious servers.  There are
characteristics of this suggestion that work much better for me (and I didn't
like the previous attempt to deal with this issue either):
* Test cases provided!
* The behavior is configurable, and the default behavior (at least with the
second round) leaves what we have today unchanged.
* The checks for malicious data are very focused on precisely the places where
HttpClient has demonstrable failure points.
* I don't see a problem with introducing an interface to capture a processing
concept prior to the 3.0 release.  In fact, I think it better to drive the
development of the specific interfaces off specific needs, issues for which
there happen to be no easy work-arounds, rather than as-yet-to-be determined
abstract concepts to solve ongoing issues for which there happen to be
work-arounds (redirect on POST needing a split of request/response).

Having said all that, I'm not sure I like the patches as-is.  I cannot decide
whether I like the original approach, where the option was configurable, and
everyone ran through the same code, or the second approach, where the header
parser could be substituted.

I'm thinking the general use case is to set the default limits to relatively
high values (not just 4K for headers, but maybe 256K), and perhaps a limit on
the total size of all headers, rather than just a limit on the number of
headers.  The defaults given - 4K for header values, 1000 headers max, could
easily trigger an out-of-memory.  For example, five threads all hitting the same
malicious server could consume 20M - enough to trigger out-of-memory failures. 
I think perhaps what wants to be limited is the maximum storage for all headers
on a particular message, for example, 256K max for one response header?

Mind you, I'm not a committer, so my opinion on this issue can at best influence
others....

---------------------------------------------------------------------
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