httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: Language bindings other that Perl
Date Tue, 12 Apr 2005 15:59:53 GMT
"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

> Next argument - we can use apreq to parse the mod_autoindex query
> string (and, accept these variables via form POST.)

Yes, assuming mod_autoindex expects query strings to appear in 
name=value form.  The basic design principle behind apreq is
to facilitate the development of a modular filter pipeline.
If someone writes a fantastic php application, and someone
else writes a fantastic mod_python filter, both of which
require access to the POST data, those apps could be chained
together if the mod_python filter is using mod_apreq2.  It seems 
like a no-brainer to me that httpd would want something like 
apreq2 in the core, but that's not the feeling I get whenever someone
asks them about it.

Joe Schaefer

View raw message