httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@apache.org>
Subject Re: 2.0.38-39 lockup problem ?
Date Thu, 20 Jun 2002 19:42:45 GMT
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

Mime
View raw message