URLRewrite ServerNameVariable Provider
IIS URL Rewrite is a powerful tool that I’ve grown quite fond of. One variable that URL Rewrite doesn’t have, which I wish it did, is the Server Name (Machine Name, Computer Name, whatever you want to call it). The server name isn’t a normal HTTP server variable. So, I wrote a simple provider to take care of that.
What I want to be able to do is provide the ServerName in an x-header variable so that Fiddler or Firebug can see the server name. This is especially useful in a web farm situation where I want to see which node serves up a particular page or image.
Note: Last week I released SiteServerDetails, a component to provide site and server details as an HTTP Module. Together these add valuable troubleshooting add-ons to a web farm.
This blog post makes the URL Rewrite Provider—called ServerNameVariable—available for anyone else that wants to use it. The code is very simple, based on this blog post.
Before I explain the install and usage, I must point out the caveats, which may affect your decision on how you use it:
- This supports ASP.NET v2.0 and greater. If you still have a v1.1 site, this will cause it to break.
- If you use it with an outbound URL Rewrite rule, unfortunately it ‘fails closed’. In other words, if it fails for any reason, it will break all page requests.
- I’ll save you the effort of testing this. If you have an ASP.NET v1.1 site and you want a global level URL Rewrite rule, you’re out of luck. The conditions are run ‘after’ the provider check fails.
- There is some performance overhead to add a X-Header to every page request. It’s very small, but worth mentioning.
So, why use this then? Well, it’s not quite as bad as all that. If you don’t have a v1.1 site, then you can register this at the server level. It will either work or fail when you set it up, it is very doubtful that it will fail over time. In other words, once it’s working it shouldn’t break unless you add another web farm node and you forget to install it there.
This is great for troubleshooting a single site. If you create a site rule then it won’t affect other sites. You can enable or disable it easily so it can be used in troubleshooting situations rather than leaving it on all the time.
To install, download from the link below, extract and run install.bat. That will add to the GAC and register the provider in IIS. So far so good. This is done without any impact to the server.
The install won’t create the outbound rule. That I left for you to do manually because of the caveats mentioned above.
The install takes care of registering it, so to use it, simply call it like you would any other server variable using {ServerNameVariable:}. Notice the required colon (:). That’s necessary when calling a provider.
The following image shows everything that is required to add an HTTP header called X-Machine-Name to every outgoing request. Of course you can filter by page type or whatever else you need. This rule will add to all page requests.
The key elements are:
- Matching scope = “Server Variable”
- Variable name = “RESPONSE_X_Machine_Name”. Note that underscores are changed to dashes in outbound rules, and it must start with RESPONSE_.
- Pattern = “.*”
- Action Type = “Rewrite”
- Action Value = “{ServerNameVariable:}”
Here’s the generated config:
<outboundRules> <rule name="Set Custom Header" enabled="true"> <match serverVariable="RESPONSE_X_Machine_Name" pattern=".*" /> <action type="Rewrite" value="{ServerNameVariable:}" /> </rule> </outboundRules>
Download: http://weblogs.asp.net/blogs/owscott/servernamevariable.zip