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 <[email protected]> To: [email protected] 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? -Randy On Wed, Mar 3, 2010 at 11:03 AM, Ashraf Amayreh <[email protected]> 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 > >o-minds.com >web development | web design >user experience | branding design > -- Randy Fay Drupal Development, troubleshooting, and debugging [email protected] +1 970.462.7450
