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 05:39:38 GMT
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).
> The next thing the content-handler does is call apreq_request_parse 
> (implicitly or explicitly).  Its only job is to pull all the data buckets 
> through the input filters.  The content-handler will block here until 
> apreq_request_parse's job is done.
> Although this is a fairly bizarre portrait of how the current code
> "works",  do you see any conceptual problems here?  If not, then reworking
> the "virtual apreq filter" into a real input filter should give us the
> current mechanism for free.

I think all we need is to split the feeder from the parser, so the 
parser always gets the request object and something that it can stick 
the parsed data into (or return it), but the parser could be feed via 
various ways: filter or implicit data passed, if the client has already 
copied r->content so it's impossible to run through filters again.

> --------------------------------------------------
> Extending support from content-handlers to filters:
> If we s/content-handler/output filter/g above, we need to figure out

output filter? you mean input, no? apreq can play only as request input 

> how to make apreq_request_new locate the parsed apreq_request_t object.
> If the "apreq filter" object is still around, maybe we could pull it
> from that?

you store the parsed data in the request pool's context. see mod_deflate 
for an example (though this one stores in the connection pool's context, 
but it's similar).

> I'm still pondering the s/content-handler/input filter/g case.
> At the moment I'm wondering why another input filter would ever
> want to call apreq_request_parse().

I don't think that's what Bill meant. I think Bill was talking about 
apreq filter to just be there and call apreq_request_parse, when it has 
consumed or copied the request body.

>>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?
> I don't see what you're concerned about here.  Can you make up
> an example for me?

Certainly. Take the SnoopFilter example and now configure it as:

Listen 8008
<VirtualHost _default_:8008>
     PerlModule MyApache::FilterSnoop
     PerlModule MyApache::Dump

     # Connection filters
     PerlInputFilterHandler  MyApache::FilterSnoop::connection
     PerlOutputFilterHandler MyApache::FilterSnoop::connection

     <Location /dump>
         SetHandler perl-script
         PerlResponseHandler MyApache::Dump
#        PerlInputFilterHandler  MyApache::FilterSnoop::request
#        PerlOutputFilterHandler MyApache::FilterSnoop::request


and change MyApache::Dump not to read the request's body and leave it 

sub content {
     return "";

now when doing:

echo "mod_perl rules" | POST 'http://localhost:8008/dump?foo=1&bar=2'

you are going to see something like this:

 >>> connection output filter
     o bucket 1: TRANSIENT


<<< connection input filter
     o bucket 1: HEAP
[mod_perl rules

as you can see the input filter that saw the body was invoked *after* 
the response phase has finished. So my question was, how to force the 
connection filter to request the next brigades which include the body, 
if nobody else does that. This part can be very tricky if you understand 
what I mean. I hope Bill can see the problem here, unless I miss something.

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

View raw message