[PATCH] handling ErrorDocument failures

[Greg Ames <gr...@apache.org>]

There have been a number of glitches with our canned error message support
(ap_send_error_response) which are caused by us trying to use two different
request_recs to send them, believe it or not.  We get into this situation when
an ErrorDocument specifies an internal redirect to a bad URI.  Current external
symptoms include the wrong Content-Type if the ErrorDocument URI points to a bad
CGI, and garbled canned error text on ebcdic boxes due to ascii data being sent
thru a charset-lite filter which expects ebcdic input. 

When ap_die detects a recursive error caused by an internal redirect to an
ErrorDocument, it saves and processes the recursive error status code, backs up
to the request_rec for the first error, and passes that to
ap_send_error_response.  We then initialize this request_rec as appropriate for
a canned error message.  But just before we start emitting the text of the
message, we switch to the newest request_rec by chasing r->next, which gets us
out of sync.  It looks like this code was added to be compatible with similar
code in ap_finalize_request_protocol.  

I can't tell from the commit logs why the code to chase r->next was added to
ap_finalize_request_protocol (rev 1.207 of modules/http/http_protocol.c).  It
takes away the caller's ability to back out to an earlier request_rec after an
internal redirect failure.  Is that important?  Dunno, but we support in 1.3 and
I see no reason to remove that support.  It's probably why the r->prev and
r->next pointers exist.

We need to send the canned error text on the same request_rec that we initialize
for that purpose in order to fix the glitches.  This patch chooses to
consistantly use the request_rec passed into ap_send_error_message to be
compatible with 1.3.  In order for that to work properly, the filter chains must
be updated to point to the earlier request_rec, backing out the changes done by
internal_internal_redirect.  

Comments?

Thanks,
Greg