httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: mod_proxy http request body code review request
Date Sun, 11 Sep 2005 17:13:52 GMT
Jeff Trawick wrote:
> On 9/8/05, William A. Rowe, Jr. <> 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;
> +         }

Yes; sendunchangedcl implies that the *Administrator* (as opposed to
module developers) have this information.  In fact, for all intents
and purposes, Administrators do not.  The issue comes down to the fact
that the Administrator is the last person who is going to have success
shooting this down when they misconfigure it.  And once misconfigured,
you will end up with hangs (short bodies) or split request bodies.

The only way to determine that the length will be assuredly unchanged,
is to modify our API to record that the filter will, or will not, modify
the body length.  And, if it will, and the filter can predetermine the
modification (say for example, one byte code page to unicode two-byte
input) then it should have the opportunity to reflect that in some new
'effective input CL' req_rec field.

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.

proxy-sendunchangedcl is one aspect of the original patch that yes, I
believed should be vetoed.  There has to be a third-way here, and that's
to fix the API and handling CL's - both request and response body CL.


View raw message