RewriteCond Directives Evaluated After RewriteRule Directives In URL Rewriting
Posted September 4, 2009 at 11:19 AM
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:
Launch code in new window » Download code as text file »
- RewriteCond %{REQUEST_FILENAME} !-f
- RewriteRule ^(.+)$ index.cfm
... I thought this was being evaluated as (pseudo code):
Launch code in new window » Download code as text file »
- 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:
Launch code in new window » Download code as text file »
- 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:
Launch code in new window » Download code as text file »
- 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.
Download Code Snippet ZIP File
Post Comment | Ask Ben | Permalink | Other Searches | Print Page
Newer Post
Ask Ben: Creating A PDF And Attaching It To An Email Using ColdFusion
Older Post
Understanding The IIS Mod-Rewrite Server Variables
Reader Comments
thanks man
