Anything that's running before the content handler, will not have modperl_callback_current_callback_get() return "PerlResponseHandler", no?
I think that's the way it ought to be, yes :)
but I think that the way filter_init is currently implemented is getting
PerlResponseHandler. at least that's what I remember the last time I looked
at it.
request filters are added into the filter chain (that's when init_filter is run) before the response callback is executed. so init_handler shouldn't see 'PerlResponseHandler'
for sure output filters are getting PerlResponseHandler, which is clearly a bug, but not one that is easily fixed.
it depends on how do you look at it. I think it's a goodness to know inside a filter what phase is it running in. So I don't mind making filters different than any other phases. Request filters are always running inside the response phase, and connection filters can be called from any pre-log phase.
anyway, I'll look again at it to be sure.
Also we probably need to optimize
modperl_callback_current_callback_(set|get) to use numerical equivalents of the phase names, instead of doing expensive memory allocs and string comparison operations. And only give the real string in the perl get API.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
