Return-Path: Delivered-To: apmail-perl-dev-archive@perl.apache.org Received: (qmail 39027 invoked by uid 500); 20 May 2003 03:23:57 -0000 Mailing-List: contact dev-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@perl.apache.org Received: (qmail 39014 invoked from network); 20 May 2003 03:23:56 -0000 Received: from main.gmane.org (80.91.224.249) by daedalus.apache.org with SMTP; 20 May 2003 03:23:56 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19Hxgk-0005fn-00 for ; Tue, 20 May 2003 05:21:19 +0200 Mail-Followup-To: dev@perl.apache.org X-Injected-Via-Gmane: http://gmane.org/ To: dev@perl.apache.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19HxgY-0005fG-00 for ; Tue, 20 May 2003 05:21:06 +0200 From: Joe Schaefer Subject: Re: [patch] C implementation of $r->content + rfc on the name Date: 19 May 2003 23:24:52 -0400 Lines: 51 Message-ID: References: <3EC34A08.2020400@stason.org> <1053085699.4416.32.camel@shou.sg.ectoplasm.org> <3EC81424.6010308@stason.org> <1053311732.15766.5.camel@shou.sg.ectoplasm.org> <1053352366.1660.29.camel@shou.sg.ectoplasm.org> <3EC960F7.2060201@stason.org> <3EC9739F.2030301@stason.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@main.gmane.org Mail-Copies-To: never User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stas Bekman writes: [...] > I haven't looked at the AP_MODE_SPECULATIVE yet :( I will. > > My main concern that the above doesn't answer is how the apreq filter > co-operates with other custom input filters. It has to be inserted on > the very top, so not to miss any transformations on the request body, > but Apache provides no API to ensure that a certain filter will be run > very last (which is actually very first in the input-terminology). It's a catch 22 at the moment. How does ANY request filter that modifies to incoming buckets ensure that it's added to the input filter chain at just the right spot? Correct me if I'm wrong, but it seems to me that ordering the input chain is something a user has to take considerable care to ensure. Up to now, I've been working under the assumption that 1) automatic filter injection for apreq will be Apache::Request::new()'s responsibility. If any handler wants to use Apache::Request, the apreq filter will push itself onto r->filters_in at this line my $req = Apache::Request->new($r); If a filter wants apreq to see its transformations, it had better already be in the filter chain before then. 2) the mod_apreq filter can also be manually injected by the user, by using the standard apache filter api, in cases where apreq might be otherwise inject itself prematurely. > I suppose that this somehow will work if apreq filter injects itself > at the very last moment and the user has to be aware of how it works, Sure, and so will the developers :-). I'm sure we'll have to make lots of modifications to the filter code once the perl API is available for testing. We'll probably also need help from httpd on how AP_MODE_SPECULATIVE is *supposed* to be implemented by transforming filters, since the typical bow-out behavior a'la mod_deflate is surely incorrect. -- Joe Schaefer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org For additional commands, e-mail: dev-help@perl.apache.org