Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 81401 invoked by uid 500); 22 Aug 2002 17:22:31 -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 81380 invoked from network); 22 Aug 2002 17:22:31 -0000 To: Stas Bekman 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> <3D651310.3050008@stason.org> From: Joe Schaefer Date: 22 Aug 2002 13:23:18 -0400 In-Reply-To: Stas Bekman's message of "Fri, 23 Aug 2002 00:36:32 +0800" Message-ID: Lines: 78 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: http://www.onlamp.com/pub/a/apache/2001/09/20/apache_2.html I'm just enjoying this substantive discussion that we're *not* having on dev :-) -- Joe Schaefer