When writing RewriteCond (rewrite condition) and RewriteRule (rewrite rule) directives in IIS Mod-Rewrite's URL rewriting configuration files, we have access to several server variables. We can get the value of these server variables using the following syntax:
So, for example, to get the name of the requested file name, we would use:
Since none of the rewrite documentation (IIS Mod-Rewrite's or otherwise) has shed too much light on what kind of values these variables hold, I figured I would run some tests to clear up my own personal confusion. I created a RewriteCond (rewrite condition) that would run against a server variable. Then, I enabled IIS Mod-Rewrite logging and ran the RewriteCond against each of the server variables that looked like it might hold useful information.
For each of the following tests, I requested this url:
Without bothering to show you the RewriteCond (rewrite condition), here is what I found:
GET /iis_mod_rewrite2/foo/ HTTP/1.1
The above were all tested with RewriteCond directives; and, while this next one is not a "server variable", I wanted to demonstrate the point that when you use a RewriteRule (rewrite rule) rather than a RewriteCond (rewrite condition), the implicit request value that you'll be testing regular expression patterns against would be:
This is all very interesting stuff. A few of the variables look like they could all be used for some good regular expression pattern matching (the basis of most all URL rewriting); but, when running pattern matching, we should think deeply about which one we choose. Obviously, when writing RewriteRule directives, we'll just use the implicit request value (foo/); but, when we write pattern comparisons in RewriteCond directives, we'll want to select the smallest possible string to test.
Regular expressions, while extremely sexy, are also costly operations. To cut down on as much of that cost possible, the target string should be of minimal length. Looking at the server variable values above, it makes sense then to always use the REQUEST_URI when performing URL-based pattern tests. This value is about half the length of any other like-value which means that our regular expressions should run twice as fast.
While this might seem like premature optimization, remember that the URL rewrite engine is being executed for every single page request made to the server (under a given configuration file). That's a lot of processing! As such, we're going to want to add optimizations where ever possible.