Geoffrey Young wrote:
the problem is with the r->main logic in mpxs_ap_run_sub_req.
with that logic, what ends up happening is that the data currently being operated on is explicity flushed. this is bad within a (streaming) filter where you are expected to call $f->print yourself, as the data is sent without your permission (you may be operating on it or not want to send it at all). it also seemed to cause infinite loop in my tests because the filter was seeing the same data over and over again.
That's is the problem with streaming filters. Nothing indicates to mod_perl whether the currently executed filter is a streaming filter or not, in fact I think you can mix and match both "methods" in the same filter. So $f->print is not expected, really.
What you are right about is that mpxs_ap_run_sub_req should flush only if run from the non-filter handler, and do nothing if run from the filter handler.
I have somewhere a prototype for the new API which tells what phase we are in, but it's possible that there is a more efficient way to tell the difference.
__________________________________________________________________ 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
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
