Order of RewriteRules

Most common first? What's the best practice?

[Bluesplinter]

What is the best practice for which RewriteRules should come first? BTW, I'm well aware that if you put a general rule ahead of a more specific one, that the general rule will "catch" the requests that the specific rule was meant to handle... I'm not asking about those cases.

What I'm curious about are the "housekeeping" rules, such as canonical hostname, lowercase URL, etc. For instance:

# don't rewrite these!
RewriteRule \.(gif¦jpg¦css)$ - [L]

# Canonical hostname
RewriteCond %{HTTP_HOST} .
RewriteCond %{HTTP_HOST}!^www\.example\.com
RewriteRule ^/(.*) http://www.example.com/$1 [R=301,L]

# Fix mixed-case
RewriteRule ^/(.*[A-Z].*) http://www.example.com/${tolower:$1} [R=301,L]

# These MUST be handled by WordPress, so short-circuit them now
RewriteCond %{REQUEST_URI} ^/(feed/¦wordpress/¦wp-)
RewriteRule . - [Skip=4]

Currently, these rules sit at the top of my vhost conf rewrite section, even though the canonical hostname/lowercase situations don't come up all that often. My thinking was that, if I don't catch those situations FIRST, then other rules might prevent them from working at all. Is that right?

Unrelated question, but my site uses Wordpress for a handful of specific "directories" (NOT just those listed in the RewriteCond). Is that last rule/cond directive the proper way to short-circuit rewriting and send those requests to the last rule (the WordPress catchall rule)?

[jdMorgan]

The only general rules I can tell you are to put your external redirects first, followed by your internal rewrites as you've done. This prevents those external redirects from "exposing" your internal URL-paths to the client.

I'm not sure what you're asking about that WP rule. The [S=4] notation will skip the subsequent four RewriteRules, not the preceding ones. I see no reason to skip the preceding rules, even for WP pages, so I'm at a loss to answer.

Jim

[Bluesplinter]

external redirects first, followed by your internal rewrites

Gotcha, thanks. That makes it very clear and easy to remember. :)

As for the skip rule, sorry I wasn't clear. The rules I posted aren't my only rules... just the first few. I have four rules after that skip rule that apply to URIs that WordPress doesn't handle. My intent in that rule is this: if the request starts with /feed/ or /wordpress/ or /wp- (or any number of other URIs), then skip down to the wp catchall rule, otherwise continue processing with the next rule.

# These MUST be handled by WordPress, so short-circuit them now
RewriteCond %{REQUEST_URI} ^/(feed/¦wordpress/¦wp-)
RewriteRule . - [Skip=4]

RewriteRule (for non-wp content)
RewriteRule "
RewriteRule "
RewriteRule "

RewriteRule "wordpress catchall rule"

My question is if this is the best way to handle this.

[jdMorgan]

Well,

RewriteRule ^/(feed/¦wordpress/¦wp-) - [S=4]

would be faster...

Jim

[Bluesplinter]

Ahh, yes it would, wouldn't it? <g> I'm new to mod_rewrite, and I still haven't quite got a handle on when to use conditions and when not to. I've been going back and forth through Rich Bowen's book so many times I think I get why they put it in a hard cover.

Thanks, Jim, you rock!

[fauzzo]

Hi,

about the rewrite rule:

RewriteRule \.(gif¦jpg¦css)$ - [L]

I have noticed that it could eventually be optimized by adding support for html js and php files.

Further more it is missing some requests as when a user asks for the direct domain name:

when the url is "www.mydomain.com" all rewrite rules will be checked.

Do you think it is possible to add '/'?

RewriteRule \.(/¦gif¦jpg¦css)$ - [L]

[Bluesplinter]

Well, you couldn't add it to that rule specific rule, because it only checks for URIs ending in gif, jpg, etc. That $ at the end of the request indicates "ends here".

In Human language, RewriteRule \.(gif¦jpg¦css)$ - [L] says:

If the request ENDS in .gif or .jpg or .css, do nothing, and quit processing rules. Of course, if you have other file extensions you don't want to rewrite, simply add 'em to the pipe-delimited list. (gif¦jpg¦css¦js¦etc)

Plus, that \. at the beginning is a literal "dot" character. So, by adding a / to the list of options, the URI you'd be looking for is ./

What you want is: RewriteRule ^/$ - [L]

The ^ says "starts with". Oh, and this is only for use in the conf file. For .htaccess usage the requests don't have that initial / character in the RewriteRules, so I guess you'd use RewriteRule ^$ - [L]...? Not sure...

Back me up here, Jim. In an .htaccess rule, what's the equivalent of ^/$

[edited by: Bluesplinter at 9:18 am (utc) on Mar. 17, 2007]

[fauzzo]

thanks for the reply and the help!

I have one more doubt: how do rewriterule and rewritecond compares togheter talking about server performance?

I think I can got similar results by using both of them: I can preceed rewrite rule with one or more rewrite condition or I can use one or more rewriterules using the [C] option.

Will it be the same for the server cpu required?

Expecially when you ask for file system checks, will rewritecond become more heavy for the server?

eg.

RewriteCond /my/real/server/path/%{REQUEST_FILENAME} -f
RewriteRule ^.* - [L]

could get symilar results of your gif/jpg/etc filter and include the / situation?

Thanks!