Forum Moderators: phranque

Message Too Old, No Replies

Excluding certain pages from existing mod rewerite rules

         

davec

9:44 am on Sep 3, 2005 (gmt 0)

10+ Year Member



Hi All

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 On

RewriteRule ^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]

jdMorgan

3:27 pm on Sep 3, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The primary problem appears to be that you've got your two new directives in the wrong order. You should always put your most-specific directives first, and then the less-specific rules after that.
Because you have used the Redirect directive, only prefix-match is used, and anything that matches "..widgets/blue-widgets" will also match "..widgets/".

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/

Also be aware that the server configuration controls the order that various modules process the directives that they recognize; Since you are using both mod_alias [httpd.apache.org] and mod_rewrite [httpd.apache.org], all directives for one will be processed before any of the directives for the other. In most "standard" configurations, mod_alias is processed first, but this is determined by the server config, and not by the order of the directives in your code.

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

davec

3:52 pm on Sep 3, 2005 (gmt 0)

10+ Year Member



Hi jdMorgan

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

jdMorgan

6:20 pm on Sep 3, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Nope, sorry. I got in a hurry and got visually-confused. There should be no slash on /permanent. The rest of what I said applies to interaction between mod_alias and mod_rewrite within one server; If the Redirect and Rewrite directives are on different servers, then this is not a concern.

Jim

davec

10:38 am on Sep 4, 2005 (gmt 0)

10+ Year Member



Thanks for the replies. I've managed to sort my problems out now.

One more question, are there any general guidelines for the size, and/or number of lines in an htaccess file, before performance starts to become an issue?

Thanks
d

jdMorgan

1:56 pm on Sep 4, 2005 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



> ...are there any general guidelines...?

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