httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Kellermann <...@duempel.org>
Subject Re: [multi-env] privatizing apreq_request_t and apreq_jar_t
Date Thu, 27 Jan 2005 17:52:30 GMT
On 2005/01/27 18:18, Joe Schaefer <joe+gmane@sunstarsys.com> 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.

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. Other env modules are
different, env_cgi is not implemented as filter (although it could
be), and automatically frees buckets which are already parsed.

You could also implement a second env_apache2 which is not an input
filter, but reads body data with ap_get_client_block(), that would not
require loading an apache module, and apreq_env_read() works exactly
like in the CGI module.

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.

Max


Mime
View raw message