Bug 33478 - mod_rewrite hangs with certain rules on x86_64 linux
Summary: mod_rewrite hangs with certain rules on x86_64 linux
Status: RESOLVED DUPLICATE of bug 31858
Alias: None
Product: Apache httpd-1.3
Classification: Unclassified
Component: mod_rewrite (show other bugs)
Version: HEAD
Hardware: PC Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-09 23:55 UTC by Darren Mobley
Modified: 2005-02-10 05:08 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Darren Mobley 2005-02-09 23:55:01 UTC
Apache Version: 1.3.33
OS: Fedora Core 2
Platform: x86_64

root@eventhorizon [/usr/local/apache]# uname -a
Linux eventhorizon.cpanel.net 2.6.10-1.9_FC2 #1 Thu Jan 13 17:52:29 EST 2005
x86_64 x86_64 x86_64 GNU/Linux

It has come to our attention that mod_rewrite, with very simple and basic rules,
are casuing apache children to hang. This has been tested so far on several
boxes, all of which are running Fedora Core 2. The problem is quite an enigma,
since very small and seemingly unrelated changes to one of the rewrite rules
will allow normal behavior. For instance, retrieving the following URL

http://x86-64.n3t.net/lsof.txt

with a .htaccess that looks like the following, works:

RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net$      [NC]
RewriteRule .*\.(jpg|jpeg|gif|bmp)$ - [F,NC]

However, add a png type to it and it hangs:

RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net$      [NC]
RewriteRule .*\.(jpg|jpeg|gif|png|bmp)$ - [F,NC]

Now for the fun stuff. Keep png in there and remove jpeg:

RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net$      [NC]
RewriteRule .*\.(jpg|png|gif|bmp)$ - [F,NC]

and it works again.
I've tested with random file extenstions, made up words, etc, there is no
pattern that I can see, but it always either works or either hangs with the same
combination, it is not random, and is reproducible every single time.

Currently I have this test domain set with the following in .htaccess:
RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net/.*$      [NC]
RewriteCond %{HTTP_REFERER} !^http://x86-64.n3t.net$      [NC]
RewriteRule .*\.(jpg|png|testing|txt|gif|bmp)$ - [F,NC]

I have copied information that should prove to be at least somewhat informative
into text files on the test domain.

http://x86-64.n3t.net/lsof.txt
http://x86-64.n3t.net/proc_pid_fd.txt
http://x86-64.n3t.net/top.txt 
http://x86-64.n3t.net/strace0.txt (full apachectl startssl -> hang strace, GET
request starts on line 4412)

A few notes:
-It does not matter if apache is start with SSL enabled or not.
-This occurs using telnet domain.tld 80 and only giving the GET /request
HTTP/1.1 and Host: x86-64.n3t.net
-It does not matter what what the domain.tld is.
-Setting RewriteEngine to "off" in .htaccess allows normal apache operation
-access.conf and srm.conf can be empty, with no changes in this behavior.
-There are no .htaccess files anywhere in the path before the last one we are
working with.
-Only happens on boxes with x86_64 libraries, only verified on FC2 boxes (we
have no others to test with)
-This does NOT hang apache entirely, only the children processes trying to
handle the GET request. Other GET,HEAD requests work just fine.

If a developer believes they can figure this out and it would help, I can most
likely grant root access to a live test server for debugging with everything in
place to reproduce the behavior.
Comment 1 Joe Orton 2005-02-10 10:24:21 UTC
Likely to be the regex issues from bug 31858; try the patch:

http://issues.apache.org/bugzilla/attachment.cgi?id=13337

*** This bug has been marked as a duplicate of 31858 ***
Comment 2 Darren Mobley 2005-02-10 14:08:39 UTC
The suggested patch *does* appear to fix this problem for all tested servers so far.
Many thanks and sorry I wasn't able to make the relation between what we were
seeing and the original ticket.