perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Tue, 20 May 2003 03:52:29 GMT
Joe Schaefer wrote:
> 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? 

By giving the control to users. They decide when each filter is inserted.

> 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.

Correct. But:

my $req = Apache::Request->new($r);

is neither SetOutputFilter and nor $r->add_output_filter(\&apreqfilter); in 
the user's code.

my point is that it's far from obvious that Apache::Request->new() is really:
$r->add_output_filter(\&apreqfilter); Perhaps Apache::Request should make 
Apache::Request::filter available to users, so that they can configure it 
manually (optionally of course). new() somehow should be aware of that.

>   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.

will mod_apreq always be available to those who build libapreq-2?

>>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.

There are too many vague things in 2.0 I haven't had a chance to play with, so 
I can't even inteligently comment on it :(

 From my experience of writing lots of filters for 2.0, hardly anybody writes 
custom filters (other than mod_perl) and since the core filters seem to work, 
nobody at the httpd land cares much about polishing the filter API.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message