On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
Lastly, why does the memory continue to be consumer after the client has terminated the connection?
Because the server doesn't realize that the connection was aborted. You can check that with $c->aborted. It could also be a bug in Apache 2. I'd check whether it works without mod_perl, e.g. using INCLUDES or some other core filter with a big file.
So it would be nice to have this in the filter (at least) documentation.
why at least? what else did you have on your mind?
So instead of:
while ($f->read(my $buffer, BUFF_LEN)) { # .... $f->print($buffer); }
have this:
while ($f->read(my $buffer, BUFF_LEN)) { return Apache::DECLINED if ($f->r->connection->aborted); $f->print($buffer); }
Unless there are some caveats that I am unaware of by doing this.
This made a big deal to some of my filters as they would keep processing large files unecessary after the client aborted.
So you did have it solve your problem? Very good.
Though I don't think Apache::DECLINED is the right return code here. Apache::DECLINED should be used when your filter decides not to filter the data, in which case mod_perl will forward the data to the next filter in chain. e.g. these two filters are equivalent:
sub out_filter {
my ($f, $bb) = @_; my $rv = $f->next->pass_brigade($bb);
return $rv unless $rv == APR::SUCCESS;return Apache::OK; }
sub out_filter {
my ($f, $bb) = @_;return Apache::DECLINED; }
I'm not sure what's the right response code to use here, since first it doesn't matter to the user (the connection is aborted), second a particual caller of the filter may ignore the response code. I'd think AP_FILTER_ERROR might be a good choice. Let me ask httpd-dev what response code should be used in such a case and I'll be back to you. Then we can document it nicely.
__________________________________________________________________ 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
