httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: dev question: apreq 2 as a filter?
Date Fri, 23 Aug 2002 07:50:59 GMT
William A. Rowe, Jr. wrote:
> At 12:39 AM 8/23/2002, Stas Bekman wrote:
>> Joe Schaefer wrote:
>>> Stas Bekman <> writes:
>>> [...]
>>>> Also I think that we should keep the old mechanism as well. In case 
>>>> someone wants to decide at run time whether to run apreq or not. The 
>>>> more flexible apreq is the better.
>>> I'm viewing the current implementation it in this way (please suspend 
>>> your disbelief until the end :) -
>>> --------------------------------------------------
>>> When a content-handler calls apreq_request_new, that does two things: 
>>> creates a placeholder for the parsed data (apreq_request_t *), and 
>>> installs the "virtual apreq filter" at the very end of the input 
>>> filters chain.  The "virtual apreq filter" holds the stack of 
>>> registered parsers (imagine we've replaced req->parsers with 
>>> req->filter in apreq_request_t).
> First, the module (content-handler or other filter) simply needs to call
> some apreq_capture() function that can do all that extra work.  Other
> modules performing the same call simply hook into the already-inserted
> filter.
> Second, you must do this call before you actually begin request processing,
> e.g. at the very beginning of your handler, or better yet, back in the 
> pre-handler
> processing phases.  All filters that need apreq data will have to do so 
> in the
> pre-handler phases or in the insert_filter phase.
> The filter's apreq_capture() function itself can do all the prep work 
> and take
> the responsibility off of the handler/other filters.

looks like you are saying the same thing as I do. Meaning that you don't 
really need it to be a filter. Right?

Also any chance that we can stick the parsed data into the request 
object? just like now we have r->args, we can have r->parsed_body, and 
apreq manipulating them both.

if you use meta buckets, you have a problem to fish the data out during 
the response phase. since the body data is interesting only during the 
request phases + request output filters, we better associate it with the 
request object.

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

View raw message