ap_send_error_response: reset r->output filters to the protocol filters.

The equivalent logic was deleted when request filters were renamed to
RESOURCE filters.  This fixes the seg faults that sometimes happen on
daedalus after a bogus 416 HTTP response is generated.

In this case, includes_filter had found an <!--#include virtual > tag, and
sent a brigade representing the data before it down the filter chain.  The
byterange filter generated the bogus 416.  ap_send_error_response essentially
starts over with a new response, but it didn't do anything to clean up the
filter chain.  So the same instance of the includes_filter got driven from the
top with the canned error text and and EOS bucket, which confused the heck
out of it.  It inserted a sentinel from the original brigade into the
error page brigade, causing problems further down the filter chain.

Submitted by:	Greg Ames, Jeff Trawick

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@94662 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/modules/http/http_protocol.c b/modules/http/http_protocol.c
index 8e5029884b69823eccabeae5bd6821314a78d459..119dbfaa8ab640c02b2b17710afea76457a70027 100644 (file)
--- a/modules/http/http_protocol.c
+++ b/modules/http/http_protocol.c
@@ -2025,6 +2025,12 @@ AP_DECLARE(void) ap_send_error_response(request_rec *r, int recursive_error)
      */
     r->eos_sent = 0;
 
+    /* and we need to get rid of any RESOURCE filters that might be lurking 
+     * around, thinking they are in the middle of the original request
+     */
+
+    r->output_filters = r->proto_output_filters;
+
     /*
      * It's possible that the Location field might be in r->err_headers_out
      * instead of r->headers_out; use the latter if possible, else the