Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at CFUNITED 2010 (Landsdown, VA) with: Joshua Cyr

RewriteCond Directives Evaluated After RewriteRule Directives In URL Rewriting

By Ben Nadel 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.




Reader Comments

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.