查找apache2.0为什么会发送错误文本和为什么杀不死

提示1：如果使用不同的request_recs来发送会导致

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. 打包错误消息支持函数ap_send_error_response里有几个小问题，此函数会导致使用2个不同的request_recs来发送。当一个ErrorDocument指明一个内部的错误URI重定向时检查出这个情况。如果ErrorDocument URI指向一个错误CGI时，当前的外部问题包含错误的Content-Type，在ebcdic盒子上混淆了打包错误文本因为ascii数据通过轻字符集过滤器发送，而此过滤器期望ecbdic输入。

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.