httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r424674 - /httpd/httpd/branches/2.0.x/STATUS
Date Tue, 25 Jul 2006 11:22:36 GMT
On Sun, Jul 23, 2006 at 10:58:39PM +0200, Ruediger Pluem wrote:
> On 07/23/2006 09:59 PM, William A. Rowe, Jr. wrote:
> > Ruediger Pluem wrote:
> >> While we are at it. There is another related report (39243, 
> >> http://issues.apache.org/bugzilla/show_bug.cgi?id=39243). Some 
> >> people feel unhappy with the hardcoded 128k buffer. They would like 
> >> to see this size configurable at runtime. Joe does not like the 
> >> idea of another directive here. Another idea that came up to my 
> >> mind: A similar problem was solved in mod_proxy_http were we slurp 
> >> in the whole request body for C-L validation (even to a file if it 
> >> is too large for memory). Maybe this code could be generalized and 
> >> used by mod_ssl too.
> > 
> > +1, but... any reason to 1) not give the hard (or soft) buffer it's
> > own directive for the upper limit size?
> 
> I don't know. Ask Joe :-)

"A config directive is the last resort of the indecisive"... but I guess 
it's going to have to happen in this case.  It would be similar in 
spirit to LimitXMLRequestBody which is some kind of bound on in-RAM 
buffering.

Buffering request bodies to disk is certainly *not* something which 
should be generalised and encouraged IMO.  It's a DoS attack waiting to 
happen in the proxy, and it would be a DoS attack waiting to happen in 
mod_ssl.  Why should you assume that disk is an unlimited resource when 
RAM isn't?  How do you know the chosen /tmp isn't RAM-backed tmpfs? etc

joe

Mime
View raw message