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 03:44:29 GMT
Joe Schaefer wrote:
> "William A. Rowe, Jr." <> writes:
>>At 12:23 PM 8/22/2002, Joe Schaefer wrote:
>>>OK, I think it's starting to gel now.  The input filter's
>>>control flow (in C) centers around ap_get_brigade.  I think
>>>the upshot for us means that converting the parsers to filters
>>>amounts to
>>>  1) reworking apreq_list_read to read from an arbitrary filter,
>>>     not just r->filters_in.  It also has to pass along the brigade
>>>     instead of clearing it.  The necessary changes to apreq_list.[ch]
>>>     are trivial.
>>>  2) literally removing the for(;;) loops from the parsers in
>>>     apreq_parser.c.  All parsers take their input from apreq_list,
>>>     so the only modifications would be to have them operate as
>>>     callbacks.  I don't think that's much of an issue at all.
>>It sounds like you have it right on target ;-)


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.

>>Finally, about the storage for the returned body chunks.  I'm not clear
>>why you propose the connection pool?  
> I don't recall ever proposing that; maybe when I was talking about
> the control flow of Stas' perl examples?  Can you be more specific?

Bill is talking about my suggestion to store the parsed data in the 
connection pool, which was obviously wrong, because the body is parsed 
during request phases and therefore should be stored in the request pool.

The is one question regarding the request pool. apreq works with query 
string as well, should it then invoke r->args when it needs that data? I 
thought it could grab it from the request headers since it's a filter, no?

I have one blind spot though. If a response phase doesn't call 
ap_get_brigade to get the body, the request input filters won't be 
invoked. The connection input filters will be invoked, when httpd will 
suck the rest of the request in before generating the output, but... 
that's too late, the response phase will be over by that time. So how do 
we do that?

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

View raw message