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
