httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: [multi-env] privatizing apreq_request_t and apreq_jar_t
Date Thu, 27 Jan 2005 18:24:21 GMT
Max Kellermann <> writes:

> On 2005/01/27 18:18, Joe Schaefer <> wrote:
>> Let's hold off on renaming it for a bit.  The big other advantage of
>> this idea is that we can also drop apreq_env_read, because all the
>> environment really has to do is service the param requests:
>> fetch-one or fetch-all.  Thus, we can remove all the
>> apreq_env_read()-related crap that's running around, and just let
>> each module manage its IO internally.
> The process of feeding env data to the parser is not well implemented,
> I had to do some trial-and-error last year. apreq_env_read() does not
> hide all the implementation details of an apreq_env_module_t.

I agree it's an ugly mess.

> Maybe it's because the env modules are too different. For mod_apreq,
> you have to delete buckets from the input filter manually, otherwise
> they eat all memory without being freed.

I don't follow.  mod_apreq has a prefetch mode, but you aren't
obligated to use it.  Response handlers written for libapreq2
should just call ap_discard_request_body and use our APIs instead.

> Other env modules are different, env_cgi is not implemented as filter
> (although it could be), and automatically frees buckets which are
> already parsed.

It doesn't need to be a filter though, because by selecting to
use libapreq, the handler has chosen it's preferred parser.

> What is your exact idea of a change here? Or first explain why
> mod_apreq is an input filter, and why apache modules might want to
> read a POST body again, after it is parsed by mod_apreq.

We don't really have the same luxury as the cgi env does when we're 
dealing with httpd.  We want libapreq2 to support apps like output 
filters and auth handlers, which will get plugged into non-libapreq2 

Joe Schaefer

View raw message