Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43248E47.30508@rowe-clan.net>
Date: Sun, 11 Sep 2005 15:06:31 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: mod_proxy http request body code review request
References: <4320C16B.4000304@rowe-clan.net>
 <cc67648e05091107151e7b8002@mail.gmail.com> <432465D0.3000404@rowe-clan.net>
In-Reply-To: <432465D0.3000404@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> Jeff Trawick wrote:
> 
>> On 9/8/05, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>>
>>> I've provided the following fork of that codebase, to try to repair the
>>> damage from the vetoed 171205 commit, in a piece by piece analysis of
>>> what's changed and why.
>>
>>
>> any particular reason we lost the sendunchangedcl setting?
>>
>> +           if (...
>> +               (r->input_filters == r->proto_input_filters
>> +               ...
>> +               || apr_table_get(r->subprocess_env, 
>> "proxy-sendunchangedcl"))) {
>> +             rb_method = RB_STREAM_CL;
>> +         }
> 
> But there's a second justification; because the new patch pre-reads up
> to some fixed bytes of input, and handle the vast majority of POST
> bodies in memory with a trusted CL, the necessity is somewhat lessened.

And I missed the third point; if the *protocol* input filter chain has
not been modified (no input request filters injected) then we continue
to presume that the CL is unchanged.  So really the only code that
triggers spool is the situation where we have injected an input filter,
and we cannot (will not) chunk the request body, and the body is larger
than the read-ahead buffer.  So this is most definately the exception,
not the rule, and the 'advantages' of some proxy-sendunchangedcl envvar
just seem not to justify the probability of misconfiguration and the
unhopefull task of diagnosing the actual symptoms.

Bill