Re: [development] mod rewrite rules question
Afraid not, adding an [L] didn't do any good. I'm still getting an internal server error that I'm presuming is caused by applying the rule indefinitely to the rewritten result. Is this the normal behavior of .htaccess files? I'm pasting the full content of the .htaccess file on the site root: RewriteEngine On RewriteCond %{HTTP_HOST} ^(.*).example.com RewriteRule (.*) ${tryme:%1}/$1 [L] I'm very sure the application is working properly because I can run it standalone and it works fine (returns either NULL or key followed by newline). -- 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
That's exactly what's happening. You are sending an internal request to another page, so .htaccess is parsed again and tries to rewrite again (and again and again). Here's a simple solution that I think will achieve what you want: RewriteEngine On RewriteCond %{HTTP_HOST} !^apps\. [NC] RewriteCond %{HTTP_HOST} ^([^.]+).example.com$ #Below stops the looping by making sure the request isn't for what you rewrote the request too. RewriteCond %{REQUEST_FILENAME} !^members/index.php RewriteRule (.*) members/index.php?sd=%1&q=$1 [L,QSA] Now in your application you'll have 2 $_GET variables. One will be 'sd' containing the subdomain and then 'q' (to use some Drupal goodness) that contains the request path. Jamie Holly http://www.intoxination.net http://www.hollyit.net On 3/3/2010 5:24 AM, Ashraf Amayreh wrote:
Afraid not, adding an [L] didn't do any good. I'm still getting an internal server error that I'm presuming is caused by applying the rule indefinitely to the rewritten result. Is this the normal behavior of .htaccess files? I'm pasting the full content of the .htaccess file on the site root:
RewriteEngine On RewriteCond %{HTTP_HOST} ^(.*).example.com <http://example.com> RewriteRule (.*) ${tryme:%1}/$1 [L]
I'm very sure the application is working properly because I can run it standalone and it works fine (returns either NULL or key followed by newline).
-- Best Regards, Ashraf Amayreh CEO | O-Minds Cell. 962 78 8099997 Tel. 962 6 5655150 Fax. 962 6 5675150
o-minds.com <http://o-minds.com> web development | web design user experience | branding design
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 <http://apps.jeeran.com> RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{HTTP_HOST} ^(.*).example.com <http://jeeran.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.comand 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/membe...) 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
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 <mistknight@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 <http://apps.jeeran.com> RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{HTTP_HOST} ^(.*).example.com <http://jeeran.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.comand 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/membe...)
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 randy@randyfay.com +1 970.462.7450
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@randyfay.com> To: development@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? -Randy On Wed, Mar 3, 2010 at 11:03 AM, Ashraf Amayreh <mistknight@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/membe... (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 randy@randyfay.com +1 970.462.7450
participants (4)
-
Ashraf Amayreh -
Jamie Holly -
nan wich -
Randy Fay