On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
> Raul Dias wrote:
> > 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?
It would really help to have some section about all the methods
available to $filter, $request and $connection handlers.
Most of the time I found some methods by browsing the list history.
I just got to know about $c->aborted() in this thread.
Sorry if this is documented somewhere, but there is no mention of it by
greping the docs dir.
[..]
> So you did have it solve your problem? Very good.
>
In a bandwidth limiter it is very important to know that a connection is
droped, so other clients can get the released bandwidth.
> 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.
I think that Apache::DECLINED is the correct behaviour as you explain
above.
In a bandwidth limiter, there is no point on holding the traffic after
the connection has being aborted. OTOH, a filter might need to finish
parsing a file even if the connection was drop to do some clean up that
might be dependent on the file content (e.g. a database transaction).
[]'s
Raul Dias
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
