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?
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.
Bill
