We are unlikely to accept a patch that modifies request_rec structures,
since that (significantly) breaks binary compatiblity.
I'd be happy to entertain a patch if you can avoid breaking binary compatibility.
Bill
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 17, 2001 1:43 PM
Subject: [PATCH] fix segfaults related to ap_custom_response()
> 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
>
