This looks exactly like the problem that Allan and I ran into when you
tried to send a request to http://foo.bar.org:443 (i.e. insecure request
over the secure port). It tried to generate an error and went into an
infinte loop. That special case was fixed by removing the SSL request
handler from the loop. This may be a bigger problem than that specific
case (or this one).
I seem to recall that the error gets created as a new request in the
ap_internal_redirect case. This seemed to cause the code to process it
from scratch. This prompted the same error to occur, etc.
Perhaps something needs to be setup or tagged differently so that the
error doesn't go back through all the same code that generated the
error condition in the first place. Just a clueless guess on my part.
Paul J. Reder
Greg Ames wrote:
> Colm MacC�rthaigh wrote:
>
>
>>also; anyone looking to replicate, I can produce it from a vanilla
>>install by adding:
>>
>>RewriteCond %{HTTP_HOST} !monkey$ [NC]
>>RewriteRule ^(.+)$ banana
>>
>>at the bottom of the standard httpd.conf , a request with a host
>>header anything other than monkey will hang the server. I've
>>just rebuilt 2.0.36 and tested against the same vailla config
>>and it doesnt happen.
>>
>
> OK, with this config I can easily duplicate the problem on .39 but not .36.
> ap_die lost its recursive error defense mechanism.
>
> We get there because mod_rewrite sees that there is a rule that maps any uri
> (including the error document uri) to "banana", then calls
> ap_os_is_path_absolute("banana"). It isn't absolute, so mod_rewrite sets a 400
> error and bails. In .36, the brower gets the canned error strings that
> indicates recursive 400 errors. In .39, we get:
>
> #0 ap_die (type=400, r=0x860ddb8) at http_request.c:130
> #1 0x08066d59 in ap_internal_redirect (
> new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x85e2d10)
> at http_request.c:482
> #2 0x08066675 in ap_die (type=400, r=0x85e2d10) at http_request.c:187
> #3 0x08066d59 in ap_internal_redirect (
> new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x85b9af8)
> at http_request.c:482
> #4 0x08066675 in ap_die (type=400, r=0x85b9af8) at http_request.c:187
> #5 0x08066d59 in ap_internal_redirect (
> new_uri=0x80e36c0 "/error/HTTP_BAD_REQUEST.html.var", r=0x858e590)
> at http_request.c:482
>
> etc etc
>
> I just committed a fix to http_protocol.c::ap_die which backs out part of rev
> 1.145. This restores the recursive error protection which is pretty important
> IMO. We can rework the fix to 1.145 if we need to.
>
> Greg
>
>
>
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
