perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
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 <stas@stason.org> 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.

Absolutely.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message