httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: svn commit: r424674 - /httpd/httpd/branches/2.0.x/STATUS
Date Tue, 25 Jul 2006 13:10:50 GMT
On 25.07.2006 13:22, Joe Orton wrote:
> On Sun, Jul 23, 2006 at 10:58:39PM +0200, Ruediger Pluem wrote:

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

I don't assume that it is unlimited and of course there should be also an
upper limit for this disk file. As you may have seen I discussed with
Bill about a more generic aproach for setasides / ap_save_brigade.
I think it makes sense to have an upper limit for memory buffering and an
upper limit for disk buffering. Whether these settings can be different for
different areas like mod_ssl, mod_proxy, etc is another story.
I totally agree that having no limit imposes a high DoS risk and even if
we have a limit this is usually for a *single* request. So it might make
sense to have an upper limit for the whole server.
Just some thoughts.


Regards

RĂ¼diger


Mime
View raw message