As one part of a fix to get scripts terminated if the connection
drops, the change below was required in the content length filter
(checking f->c->aborted). What worries me is that this check probably
needs to be added elsewhere as well.
core_output_filter was previously changed to return APR_SUCCESS on
failure in order to keep non-HTTP-status codes out of access_log
because the return value from the filter was getting logged instead of
r->status. Requiring filters to return HTTP status codes (or
APR_SUCCESS if the error won't map to HTTP status) flies in the face
of the documentation in util_filter.h. Also, many of these possible
errors are encountered after the header (and thus HTTP response code)
has already been passed down by the http header filter. But if we
already wrote "200 OK" (or whatever) to the client it doesn't seem
proper for a filter to subsequently return 500 when something blows up
and then for the 500 to be logged as the status of the request.
Somehow it seems more intuitive for J. Random Filter to be able to
set/check function return values and set r->status if necessary and
not worry about c->aborted (except for special filters like
core_output that need to set c->aborted sometimes).
Maybe I can find time to review any old discussion about this to see
if there were good reasons for changing the output filter interface :)
Index: server/protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.119
diff -u -r1.119 protocol.c
--- server/protocol.c 2 Oct 2002 13:41:45 -0000 1.119
+++ server/protocol.c 29 Oct 2002 15:12:35 -0000
@@ -1260,7 +1260,7 @@
APR_BRIGADE_INSERT_TAIL(b, flush);
rv = ap_pass_brigade(f->next, b);
- if (rv != APR_SUCCESS) {
+ if (rv != APR_SUCCESS || f->c->aborted) {
apr_brigade_destroy(split);
return rv;
}
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
