Hi there. I wrote in earlier this week about bug #6336 and
ap_custom_response (basically, any use of ap_custom_response() seems to
guaruntee a segfault in ap_die() on the next error response). The
attached patch (againsts 1.3.20) seems to fix the problem. I had
someone at work shove about 3.5 million requests into it, and the
server seems stable with the patch applied.
Here is what I did:
* Added a char** response_code_strings field to the end of request_rec
* Modified ap_custom_response() to set r->response_code_strings ...
previously, it set conf->response_code_strings, using memory from
r->pool. After the current request was finished,
conf->response_code_strings still pointed to stuff in the now-defunct
r->pool, and the next time ap_die() tried to use it to find an
ErrorDocument, it'd segfault.
* Modified ap_response_code_string() to check if the request_rec has a
response_code_string that applies. If it doesn't, it then checks the
per-dir config as before. This, to me anyway, is the expected
behavior: if I call ap_custom_response(), I mean to be setting a
custom response for only the current request, and I expect it to
override the directory configuration.
If anybody with more apache-hacking experience wants to suggest another
solution, I'm game to try implementing it. But as far as I can tell,
without a fix of some sort, ap_custom_response() is basically
unusable.
--
thanks,
Will
ap_custom_response.patch.gz
