Skip to main content
Ben Nadel at BFusion / BFLEX 2010 (Bloomington, Indiana) with: Matt Boles
Ben Nadel at BFusion / BFLEX 2010 (Bloomington, Indiana) with: Matt Boles

RewriteCond Directives Evaluated After RewriteRule Directives In URL Rewriting

By on

This is a minor point, but an important one regarding the control flow of directives within IIS Mod-Rewrite's URL rewriting configuration files. When I first looked at the RewriteCond (rewrite condition) and RewriteRule (rewrite rule) directives, I thought of them like programmatic IF-Statements such that the RewriteCond directives would be evaluated before the RewriteRule. So, for example, if we have the statement collection:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+)$ index.cfm

... I thought this was being evaluated as (pseudo code):

if (REQUEST_FILENAME does not exist){
	if (REQUEST.Matches( "^(.+)$" )){
		rewrite( "index.cfm" );
	}
}

According to the IIS Mod-Rewrite documentation, however, my assumption is actually way off. In fact, the order of evaluation of directives is quite the opposite; RewriteCond directives are not evaluated before RewriteRule, but rather after the RewriteRule as secondary conditional assertions. As the configuration file is executed, the RewriteRule regular expression is applied to the request; if the RewriteRule regular expression matches, then and only then are the preceding RewriteCond directives evaluated; and, if all the RewriteCond directives are true, the RewriteRule directive is applied to the request.

So, taking the same example above, the actual control flow is more like this:

if (REQUEST.Matches( "^(.+)$" )){
	if (REQUEST_FILENAME does not exist){
		rewrite( "index.cfm" );
	}
}

While the outcome would be the same for us in either of the pseudo code examples above, not understanding the order of operations could lead to redundancy and extra processing. Take this collection of directives for example:

RewriteCond %{REQUEST_URI} /$
RewriteRule ^(.+)$ index.cfm

In the above collection, the RewriteCond directive requires the requested URL to end in "/". Now, if we operated under the assumption that the RewriteCond directives were processed first, then we would assume that only the RewriteCond directive would execute, evaluate to false, and the RewriteRule would be passed-over. However, what actually happens is that the RewriteRule is evaluated, matches the request, then evaluates the RewriteCond directive to see if the rewrite should take place. Now, we have two regular expressions being applied rather than just one (had we put the slash-constraint in our RewriteRule pattern).

This might seem like a contrived example, but, by not fully understanding the control flow of the IIS Mod-Rewrite rules engine, I could end up with a bunch of processing that I don't need. I am sure that for many of you familiar with the URL rewriting world, this is a no-brainer; but, as someone who creates a thousand compound IF-Statements every day, this control flow was not the expected behavior.

Want to use code from this post? Check out the license.

Reader Comments

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel