Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 61247 invoked by uid 500); 27 Aug 2002 03:25:59 -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 61236 invoked from network); 27 Aug 2002 03:25:59 -0000 Message-ID: <3D6AF136.7000605@stason.org> Date: Tue, 27 Aug 2002 11:25:42 +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: "William A. Rowe, Jr." , Issac Goldstand , apreq list Subject: Re: dev question: apreq 2 as a filter? References: <"William A. Rowe, Jr."'s message of "Mon, 26 Aug 2002 09:08:47 -0500"> <200208212349.40583.chatgris@mediapow.com> <3D647453.7030704@stason.org> <3D651310.3050008@stason.org> <5.1.0.14.2.20020822123542.02919dc8@pop3.rowe-clan.net> <3D65AF9D.7060908@stason.org> <3D65CA9A.4050706@stason.org> <5.1.0.14.2.20020823035453.02bf93b8@pop3.rowe-clan.net> <3D6602E1.9070600@stason.org> <5.1.0.14.2.20020825004851.02a71ea0@pop3.rowe-clan.net> <5.1.0.14.2.20020826090113.02da9e60@pop3.rowe-clan.net> <5.1.0.14.2.20020826122329.07398420@pop3.rowe-clan.net> 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: > "William A. Rowe, Jr." writes: > > >>At 11:18 AM 8/26/2002, Joe Schaefer wrote: > > > [...] > > >>>For instance, it would be a bad thing if the content-handler injects >>>apreq at the end of the filter chain, then "does something" to cause >>>apreq to prefetch some post DATA, and *then* wants to inject utf-8 >>>somewhere upstream from the apreq filter. >> >>That's easy... when you insert a filter, you can choose to insert it before >>or after another filter. Any filter that wants apreq results before processing >>it's own input filtering MUST insert itself behind the apreq filter, after >>calling >>the fn to inject and initialize the apreq filter. > > > That's not the case I'm worried about. I'm worried about the case > where the to-be-inserted filter wants to modify the input stream > *before* apreq starts parsing it. The to-be-inserted filter isn't > interested in the apreq data whatsoever. > > For example, someone may write a filter whose job is to run a SAX-ish > XSL transform on the incoming "text/xml" data. (Perhaps even as a fixup > for apreq's xml parser). We had better not have prefetched any of the > POST before that filter is injected upstream. If the apreq filter copies the data it reads elsewhere, without changing anything passing through it, any other filters coming after it should be just fine, no? In data => filterA => filterAPREQ => filter B => content handler => \ / -->--->------------->--- If that's correct, apreq filter should be placed on the list of filters, *after* filters that convert network packed/encoded data into normal data (ssl, deflate filters), but *before* any special purpose filters (.e.g. XSL transform filters, utf8, etc) because the content handler wants the body as it was sent by the client, without making any transformations on it. Therefore it should be possible to insert special purpose filters after the apreq filter, which may mangle the original body, but this shouldn't affect the body seen by apreq and any content handler calls to apreq_*(). __________________________________________________________________ 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