My patch is at
Will Lowe's original patch is at
http://www.geocrawler.com/archives/3/417/2001/8/100/6450687/
There were a couple of things I didn't like there:
a) reusing core_dir_config as a request config structure
(when I first looked at patch I assumed that Apache 1.3 did this ugly thing
already, but nope)
b) if module registers a custom response string for 302 and there is an
ErrorDocument for 301 and the actual HTTP status is 301, we should find the
ErrorDocument... Will Lowe's patch would look no further than the request
config if ap_custom_response() had been called for any status code on this
request; probably not a common issue, but still...
http://www.apache.org/~trawick/13_custom_response_patch
In order to hit the problem, directory walk has to be circumvented by a module
that does not serve out of the filesystem (translate-name hook) and there's
can't be Location directives of interest. Otherwise, core will create
core-dir-config out of the request pool and there will be no corruption of the
permanent core-dir-config structures.
But with the right combination of modules, it is very easy to see that when a
module calls ap_custom_response() on some flow, subsequent requests with no
such call will still get the previously-registered response string.
While I have not hit crashes myself in testing, it is easy to see how the
response code table and/or response code string allocated from the request pool
(still pointed to by permanent per-dir-config) can later be reused for other
purposes and the pointers in the response code table are no longer valid
pointers but instead are something else entirely.
