httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Language bindings other that Perl
Date Tue, 12 Apr 2005 16:15:16 GMT
At 10:59 AM 4/12/2005, Joe Schaefer wrote:
>"William A. Rowe, Jr." <> writes:
>> At 09:23 AM 4/8/2005, Jeffrey Horner wrote:
>>>Well, it seems to me that it should happen. What's holding back the
>> Nothing, but to present as a patch to httpd/trunk/ and arguments
>> for its inclusion.
>> Arguments, if we streamed large response bodies to a file for the
>> benefit of all filters (either in addition or not to the individual
>> mime file streams) - this would permit large POST bodies to work
>> with SSL renegotiation.
>mod_apreq2 is a lazy, transparent filter, so that shouldn't be 
>a problem for output filters that use apreq.  The range
>of supported per-request phases is supposed to run the full gamut, 
>or at least from auth handlers to output filters.  Since the
>mod_apreq2 filter always sits behind ap_http_filter, I don't
>see how SSL renegotiation could be negatively impacted by its

. User POSTs a 100MB file upload.

. apreq is invoked to stream this body

. mod_ssl triggers renegotiate

. body exists ... stream *entire* 102MB data stream into a tempfile

. apreq writes 100MB file mime body into a tempfile

. handler grabs the body from apreq after validating the cert.

You don't agree that a cumulative 202MB temp file usecase, double
store of the same body, is ineffectual?

Using file buckets, it would be trivial for apreq to create a file
bucket into the common tempfile, representing the mime body.  This
would save the redundant double-storage of the uploaded body or
other sorts of body streams.



View raw message