perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Mon, 19 May 2003 22:55:51 GMT
Joe Schaefer wrote:

>>Well, then what is the better solution if 2 different modules need
>>access to the POSTed data (I didn't look at how apreq handles this) ?
> In (the C API for) apreq-2, we inject a filter into the input chain.
> It's essentially a passive "tee":
> incoming POST data =>  [ap_http_filter] => ... 
>                      ... => [apreq filter] => ... [content handler]
>                                  |
>                                  |
>                                  v
>                               [parser] -> [hook] -> apr_table

> The filter is only injected once per-request, and the POST data should
> available to any phase of the request.  For example, suppose an aaa 
> handler needs apreq-2 to look for something in the POST data.  The 
> apreq filter will first prefetch some (configurable) amount of the 
> POST data, and then
>   1) store the raw POST data in an internal brigade,
>      so the actual content handler will be able to get it later on,
>   2) send a copy of whatever it got to the parser, to honor
>      the aaa handlers' request.

This is going to be a problem, btw. How users are going to trigger that "tee"? 
If someone needs to read the POST data in the pre-response handler, can they 
do it? What if response handler injects a new input filter? How do you ensure 
that apreq is injected on the very top?

I think that by default apreq should work as before, simply sucking the POST 
data on demand. Only if a user configures it as an input filter, they have to 
have an explicit control over it, i.e. they have to use the mod_perl API to 
insert that filter explicitly.


Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message