On 07/23/2006 09:59 PM, William A. Rowe, Jr. wrote: > Ruediger Pluem wrote: > >> >> On 07/23/2006 09:02 AM, William A. Rowe, Jr. wrote: >> >>> Criminy!!! If you are curious how many people really need this fix, >>> figure >>> only half are ready to upgrade now to 2.2.x and scroll down through the >>> list >>> of email notifications. Never seen such a monstrous list in my life >>> after >>> I clicked submit to change the bug title. >> >> >> 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 :-) > > for the setaside code, we recently ran into this in John's new > phpapachefilter > code, and were thinking that if the setaside had an arguement for it's max > setaside allocation, (per setaside, so phpfilter could have a > PHPMaxFilterScript > size directive, while ssl could have a SSLMaxRenegotiateBody size > directive) > then the user could avoid excessive setasides. > > Since excessive setasides would -usually- be caused my misconfiguration > (in the > php filter case, trying to filter downloaded tar.gz files or something > silly), > capping setaside could be goodness. Sounds like a good idea to me to work this either into the setaside code on apr-util side or into ap_save_brigade, because excessive setasides can blow up the whole server. So better a bunch of error messages and some wrong delivered content than a blown up server where nobody knows why :-). But I guess for backwards compatibility we need to retain the old versions of setaside / ap_save_brigade that simply call the new ones with a limit of 0 (=unlimited). Regards Rüdiger
