httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: dev question: apreq 2 as a filter?
Date Thu, 22 Aug 2002 17:23:18 GMT
Stas Bekman <> writes:

> Joe Schaefer wrote:


> > 
> > snoop ("connection", ...
> > snoop ("request", ...
> > snoop ("connection", ...
> > snoop ("request", ...
> > snoop ("connection", ...
> > snoop ("request", ...
> > 
> > but NOT in a store-and-forward 'ish
> > 
> > snoop ("connection", ...
> > snoop ("connection", ...
> > snoop ("connection", ...
> > snoop ("request", ...
> > snoop ("request", ...
> > snoop ("request", ...
> > 
> > It looks to me (based on the webpage) like the second case 
> > is what's really happening.  Is that right?

Yes, I am wrong. :-)

> I guess my explanations aren't good enough :( Dump is a response 
> handler, it has nothing to do with filters. it just reads the query 
> string and the body and echos them back as a response. it could just say 
> "hello". The point of Dump is that it calls $r->content which invokes 
> request input filters. If you don't call $r->content request input 
> filter will never be called at all.

Oops- I'm sorry for not looking at the example more carefully.
I'll try to do better in the future.

> All filters are inside FilterSnoop, try removing the request filters and 
> see how the connection filters work alone, then just the request 
> filters, then both. Filters never consume more then one brigade unless 
> you want to buffer up, usually they process the brigade and forward it 
> further.

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.


> in reality filters interleave because they are stacked and each brigade 
> goes through all filters in the stack.

Yup- that's what I needed to know.  Do I have it right now?

> Give me some more time, I'll add more filter examples tomorrow.

No need to rush,  I came across an onlamp article by Ryan Bloom
that gives lots of jucy details:

I'm just enjoying this substantive discussion that we're *not* 
having on dev :-)

Joe Schaefer

View raw message