[development] mod rewrite rules question

nan wich nan_wich at bellsouth.net
Wed Mar 3 21:23:14 UTC 2010

Open a core issue on that. Since 6.16 is in the works, this could be good timing.
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

From: Randy Fay <randy at randyfay.com>
To: development at drupal.org
Sent: Wed, March 3, 2010 1:27:13 PM
Subject: Re: [development] mod rewrite rules question

Just an FYI: Dreamhost recently disallowed FollowSymLinks on all their servers, so the standard Drupal .htaccess (and sites/default/files/.htaccess) will cause a 500 error. Replacing the instances of FollowSymLinks with SymlinksIfOwnerMatch resolves this on Dreamhost.

I only mention this because anybody who perked up at the mention of FollowSymLinks might want to know.

Apparently Dreamhost has encountered a security risk of using FollowSymLinks. I wonder if we should update the Drupal ..htaccess and sites/default/files/.htaccess in line with this. Any opinions?


On Wed, Mar 3, 2010 at 11:03 AM, Ashraf Amayreh <mistknight at gmail.com> wrote:

Well, the reason for the internal server error, awkwardly enough, is because I had FollowSymLinks inside the directory tags inside the virtual host tags
>Options Indexes FollowSymLinks
>Removing it solved the internal server error. In fact, I do use symlinks so I was puzzled on what to do. Adding Options +FollowSymLinks in the .htaccess file did it (it's already done in Drupal's .htaccess file). Strangely enough, you cannot declare this inside the directory tags but could through .htaccess and probably outside the directory tags too.
>I also noted that "NULL" must be sent without a newline. For anyone who may try this in the future.
>The final look for the rewrite rules are as follows: 
>RewriteCond %{HTTP_HOST} !^apps.example.com
>RewriteCond %{REQUEST_FILENAME} !-f
>RewriteCond %{REQUEST_FILENAME} !-d 
>RewriteCond %{HTTP_HOST} ^(.*).example.com
>RewriteRule ^(.*)$ ${res:%1}$1 [QSA]
>RewriteCond %{REQUEST_FILENAME} !-f
>RewriteCond %{REQUEST_FILENAME} !-d
>RewriteCond %{REQUEST_URI} !=/favicon.ico
>RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
>I am bumping into the infinite loop problem though. And I'm not sure the proposed solution could work. In case the rewrite was transparent (app returns NULL), there's no way to know on future requests that I've done a previous rewrite. For example:
>If abc.example.com returned a NULL, the URL will still be abc.example.com and not abc.example.com/members so I can't check against "members" to prevent an infinite loop, unless I misunderstood the proposed solution. With the above rewrite rules, I'm getting a very strange phenomena for non-rewriteen URLs (when the app returns NULL):
>http://abc.example.com/ar/members/abc/ar/members/abc/ar/members/abc/ar/members/abc/ar/members/abc/ar/abc/16474 (etc)
>Of course it's too long to paste here. The error I get is 414 (Request-URI Too Large)
>Any help still appreciated :) 
>Best Regards,
>Ashraf Amayreh
>CEO | O-Minds
>Cell. 962 78 8099997
>Tel. 962 6 5655150
>Fax. 962 6 5675150
>web development | web design
>user experience | branding design

Randy Fay
Drupal Development, troubleshooting, and debugging
randy at randyfay.com
+1  970.462.7450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20100303/711ea0a1/attachment.html 

More information about the development mailing list