Forum Moderators: phranque
I'm having a couple of problems with adding exceptions to a rewrite rule I'm using to create search engine friendly pages.
The existing htaccess file contains the following code:
RewriteEngine OnRewriteRule ^typo3$ - [L]
RewriteRule ^typo3/.*$ - [L]
RewriteCond %{REQUEST_FILENAME}!-f
RewriteCond %{REQUEST_FILENAME}!-d
RewriteCond %{REQUEST_FILENAME}!-l
RewriteRule .* index.php
This is standard from the real url module with typo3 and pushes everything through the index.php file and rewrites in the format http://www.example.com/pageidnumber/
This is a new site, however we want to redirect some traffic from and old site through to it, however the rules above are overwriting what I want to do. For example on domain 2 I have a page that I want to redirect to a page on domain 1 so in the htaccess for domain 2 I have for example
Redirect permanent /widgets/ http://www.example.com/580/
Redirect permanent /widgets/blue-widgets/ http://www.example.com/581/
The first line works, and redirects to www.example.com/580/ however the next line is a directory deeper and ends up redirecting to www.example.com/580/blue-widgets/
Is there a way of setting up a section which says don't include certains lines in the catch-all rewrite.
Secondly I would like to add some redirects in the above format to domain 1. eg. redirecting requests for www.example.com/widgets/ to the correct page id, so I can promote real sounding urls in emails and literature.
Hope this makes sense. Basically the rewrite rules from existing domains such as domain 2 are being changed by the rewrite rules on domain 1 and so I'd like to exclude these.
Thanks
Dave
<edit: corrected mistake>
[edited by: jdMorgan at 3:29 pm (utc) on Sep. 3, 2005]
[edit reason] Example.com [/edit]
You're also missing the initial slash.
Redirect /permanent /widgets/blue-widgets/ http://www.example.com/581/
Redirect /permanent /widgets/ http://www.example.com/580/
However, since you say your first Redirect directive works, it appears that your server processes mod_alias before mod_rewrite, and therefore all of your Redirects will be applied before any RewriteRules.
If this module-order-dependency causes you problems in the future, you might wish to consider using mod_rewrite for all internal rewrites and external redirects. Since all directives would then be processed by a single module, you could control their execution/application order.
Jim
Thanks very much for the reply. I'm not sure I explained the myself very well. The Redirect permanent lines are on one domain (domain2) which redirect pages through to another (domain) which has the RewriteRule commands.
I tried added a slash before the permanent, but this causes an internal server error? I will have a go at using rewrite rather than redirect and see how it goes.
Thanks
d
No, because it depends on the performance of your server hardware and the number of requests your server handles per unit time. Some sites get along famously with a 48kB .htaccess file, while others will degrade noticeably at half of that.
Some things that will help:
Put rules in order (when possible) of most-frequently-applied first.
Use the [L] flag on RewriteRule to stop mod_rewrite parsing when a rule matches and is invoked.
Use efficient patterns, i.e. avoid the use of ".*" when a more-efficient pattern can be used.
Make the RewriteRule pattern as specific as possible; RewriteConds are not processed unless the rule pattern matches.
Avoid the use of filesystem checks, i.e. using the -f, -d, and similar flags on RewriteCond. If you must use them, then use a very specific RewriteRule pattern and additional preceding RewriteConds to minimize the number of cases where the check is done.
Avoid the use of the server variable %{REMOTE_HOST}. Using this variable requires your server to do a reverse-DNS lookup on the IP address to get the remote host name, which means your server must send a request to the DNS system each time this variable is invoked. So, for each request your server receives from clients, it must issue another request to the internet and wait for a response before it can respond to the client request. If at all possible, use %{REMOTE_ADDR} to control access by IP address or IP address range instead.
These are just a few pointers -- I'm sure I forgot something.
Jim