You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joachim Zobel <jz...@heute-morgen.de> on 2006/08/25 23:08:17 UTC
ap_core_output_filter returns APR_SUCCESS on error
Hi.
The core output filter is doing the following if the client unexpectedly
closes the connection:
if (rv != APR_SUCCESS) {
ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c,
"core_output_filter: writing data to the network");
... cleanup
/* The client has aborted, but the request was successful.We
* will report success, and leave it to the access and error
* logs to note that the connection was aborted.
*/
return APR_SUCCESS;
}
Unfortunately my upstream filter does not read the logs. How else can I
find out there was this error from an upstream filter? I am doing a SAX
parser module (mod_expat) and I want it to be able to handle large
amounts of data. If there are some 100M of data ahead, the parser should
stop if a client closes the connection.
Or is it possible to change the above return to an error value? It looks
wrong to me anyway, but I think this was done for a reason.
Sincerely,
Joachim
Re: ap_core_output_filter returns APR_SUCCESS on error
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 26, 2006, at 8:29 AM, Joachim Zobel wrote:
> Am Freitag, den 25.08.2006, 23:22 +0200 schrieb Ruediger Pluem:
>> c->aborted is set to 1 in this case. Just check for it once you
>> return from ap_pass_brigade.
>
> Thx. For the convienience of those who google:
>
> rv = ap_pass_brigade(f->next, sctx->bb) ;
> if (rv != APR_SUCCESS
> || f->c->aborted) {
> return rv;
> }
>
> is what I do for now.
>
And it's what other areas in httpd do as well (see
ap_content_length_filter()
for example).
> I just found the header (in 2.2.2) for ap_pass_brigade says:
>
> Pass the current bucket brigade down to the next filter on the filter
> stack. The filter returns an apr_status_t value. If the bottom-most
> filter doesn't write to the network, then ::AP_NOBODY_WROTE is
> returned.
>
> IMHO it is a bug if software does not behave as documented. How do we
> fix this? Should ap_pass_brigade check c->aborted an adjust the
> filters
> return accordingly? This is much preferable to having every filter do
> what I do now.
>
Note that we still try flushing the connection even if
aborted is true. So the assumption is that even with
aborted, we may have *something* on the line.
Documentation
Posted by Guy Hulbert <gw...@eol.ca>.
Hi all.
I am getting a little more serious about working on the perchild mpm.
Before I start, I would like some documentation at the level of the
example below but with a more global perspective.
If none exists, then I will put something together.
I understand there are lists for apr and for documentation and there are
also some books available. Are any of these sources likely to be
relevent or is what I'm looking for strictly confined to comments in the
code ?
Any pointers would be welcome. If there is no web page that summarizes
this perhaps I will start on that.
tqvm
--gh
On Sat, 2006-26-08 at 14:29 +0200, Joachim Zobel wrote:
<snip>
>
> I just found the header (in 2.2.2) for ap_pass_brigade says:
>
> Pass the current bucket brigade down to the next filter on the filter
> stack. The filter returns an apr_status_t value. If the bottom-most
> filter doesn't write to the network, then ::AP_NOBODY_WROTE is
> returned.
>
> IMHO it is a bug if software does not behave as documented. How do we
<snip>
Re: ap_core_output_filter returns APR_SUCCESS on error
Posted by Joachim Zobel <jz...@heute-morgen.de>.
Am Freitag, den 25.08.2006, 23:22 +0200 schrieb Ruediger Pluem:
> c->aborted is set to 1 in this case. Just check for it once you return from ap_pass_brigade.
Thx. For the convienience of those who google:
rv = ap_pass_brigade(f->next, sctx->bb) ;
if (rv != APR_SUCCESS
|| f->c->aborted) {
return rv;
}
is what I do for now.
I just found the header (in 2.2.2) for ap_pass_brigade says:
Pass the current bucket brigade down to the next filter on the filter
stack. The filter returns an apr_status_t value. If the bottom-most
filter doesn't write to the network, then ::AP_NOBODY_WROTE is
returned.
IMHO it is a bug if software does not behave as documented. How do we
fix this? Should ap_pass_brigade check c->aborted an adjust the filters
return accordingly? This is much preferable to having every filter do
what I do now.
Sincerely,
Joachim
Re: ap_core_output_filter returns APR_SUCCESS on error
Posted by Ruediger Pluem <rp...@apache.org>.
On 08/25/2006 11:08 PM, Joachim Zobel wrote:
> Hi.
>
> The core output filter is doing the following if the client unexpectedly
> closes the connection:
>
> if (rv != APR_SUCCESS) {
> ap_log_cerror(APLOG_MARK, APLOG_INFO, rv, c,
> "core_output_filter: writing data to the network");
>
> ... cleanup
>
> /* The client has aborted, but the request was successful.We
> * will report success, and leave it to the access and error
> * logs to note that the connection was aborted.
> */
> return APR_SUCCESS;
> }
>
> Unfortunately my upstream filter does not read the logs. How else can I
> find out there was this error from an upstream filter? I am doing a SAX
c->aborted is set to 1 in this case. Just check for it once you return from ap_pass_brigade.
Regards
Rüdiger