httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: dev question: apreq 2 as a filter?
Date Thu, 22 Aug 2002 16:36:32 GMT
Joe Schaefer wrote:
> Stas Bekman <stas@stason.org> writes:
> 
> [...]
> 
> 
>>I'll mention again this URL:
>>http://perl.apache.org/docs/2.0/user/handlers/handlers.html#All_in_One_Filter
>>which demonstrates that filters are quite simple once you understand how 
>>they work, and that's the goal of that URL -- to help you understand that.
> 
> 
> 
> I agree that Dump.pm is very simple, But I don't *like* the 
> idea of using a store-and-forward type filter (which is only 
> called one time per request, and consumes its entire input brigade
> before passing control to the next filter in the chain).  
> 
> The FilterSnoop.pm code looks much more promising to me,
> which appears to only consume $readbytes of data per call.
> In that example, what I'd naively hope to happen is that apache 
> would execute the filters in this order:
> 
> 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?

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.

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.

Also remember that the C implementation will be a "bit" longer, so it's 
a good idea to grap the concepts with perl implementations ;)

Though currently there is a problem with perl filters, as you don't have 
access to connection context, so you cannot setaside data. which is 
easily done in C, because you have the raw access to filters. I guess 
this will be fixed in perl at some point. But for apreq this doesn't 
matter, as it's pure C.

one more thing. Look at the two diagrams
http://perl.apache.org/docs/2.0/user/handlers/handlers.html#HTTP_Request_Cycle_Phases
and
http://perl.apache.org/docs/2.0/user/handlers/handlers.html#Connection_Cycle_Phases

connection filters see all the data, including headers. request filters 
see only the request and respond *bodies*. so this losely can be shown as:

connection_filter(headers_in)
connection_filter(body_in)
request_filter(body_in)
...
request_filter(body_out)
connection_filter(headers_out)
connection_filter(body_out)

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

when you grok how this works and know how to improve my explanations 
patches or just comments are very welcome.

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

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message