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 Sun, 23 Jul 2006 20:58:39 GMT


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

Mime
View raw message