Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 27904 invoked by uid 500); 22 Aug 2002 16:36:48 -0000 Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list apreq-dev@httpd.apache.org Received: (qmail 27887 invoked from network); 22 Aug 2002 16:36:48 -0000 Message-ID: <3D651310.3050008@stason.org> Date: Fri, 23 Aug 2002 00:36:32 +0800 From: Stas Bekman Organization: Hope, Humanized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Schaefer Cc: Joshua Moore-Oliva , apreq-dev@httpd.apache.org Subject: Re: dev question: apreq 2 as a filter? References: <200208212349.40583.chatgris@mediapow.com> <3D647453.7030704@stason.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Joe Schaefer wrote: > Stas Bekman 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