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.

If you prefer to see this in a video format, here’s a video on URL Rewrite outbound rules, and in the 2nd half of the video I show the install and usage for ServerNameVariable.

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.

image

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

Source code: http://weblogs.asp.net/blogs/owscott/servernamevariable_Source.zip

10 Comments

  • Any chance you can put the source code for the ServerNameVariable.dll in the .zip file? I'm still looking for more comprehensive treatments of customer providers for URL Rewrite, and this looks like it could be helpful. Thanks.

  • Hi Donnie,

    Sure thing. I just added it with a link at the bottom to the source code. It's a Visual Studio 2010 project. This link (http://learn.iis.net/page.aspx/804/developing-a-custom-rewrite-provider-for-url-rewrite-module/) that I mentioned in the blog post is a great starting point.

  • I've already worked through the article at the link you mentioned. Not as helpful as I expected. A spec doc for what custom providers are supposed to do and how they do that would be helpful. But your article and the source are removing the scales a bit more...

    Many thanks!

  • Hi Donnie, it is daunting at first. After you walk through it a couple time it will make more sense. Glad that you're making headway.

  • Hi Scott,

    Sorry been so late replying to this.

    I am missing something here but I see little point in this.

    I simply at the computer level in IIS manager set the HTTP Response Header to the name of the server.

    Surely that is the easiest to do and what many admins have been doing for years.

    No rewrite rule, no compatibility problems with different technologies like .net 1.1,etc and not the extra processing that involves URLrewrite, not the problem with conflict rewrite rules, and the only extra overhead is that you have to manually type in the server name/code each time.

    I am curious can you explain the plus points to your, admittedly clever but I feel over engineered method for displaying the server details.

  • Hi Rovastar,

    Thanks for your reply. What you propose is great for situations where IIS isn't automatically kept in sync between web servers. If you can set it on each server, you're right, you can avoid something like this. However, if you need it to be dynamic because you use Shared Configuration, then a static value can't be applied uniquely per web server.

  • Hi Scott,

    Yes that is true you cannot do it for the shared config scenario. Thanks for scenario where it could be needed.

    Personally I am not a great fan of shared config but the debate about individual configs and the problems synching this content versus the shared configs and the problems of a single point of failure of such critical files can wait for another time. :)

    Anyway all is not lost here as the shared configs still have separate web.configs for each site and in there you can put separate server ID information headers. Which is the way that I do would do this. I often just modify the default x-powered-by header to say more.

    Having server specific headers is a useful tool and I am still surprised how many large farm environments I consult on still don't give this information. Browsing around the web I look at headers for popular sites and nothing often is there (I keep firebug, fiddler, header spy, etc add-ons installed in my firefox browser and rollover for Microsoft IIS sites)

    It is so useful for troubleshooting on farms.

    Hope that helps someone at least. :)

  • Thanks Rovastar for the comments. You're right, the local web.config files also allows unique information per node ... as long as they also aren't kept in sync. So it depends on the situation. If there is a global or a site config that is different per server, then they can set it how you recommend. I would prefer that on some webfarms too because there are less moving parts. For those that don't have the luxury of something different per server, that's where this small utility comes in handy.

    Sounds like you have a good pulse on webfarms in your environment and out on the web.

  • Thanks for the post Scott, I know I'm a little late, but found this very useful. I just wondered if there were any security considerations surrounding handing our your server names?

  • Hi Dave,

    Good question. It really depends. There is software out there that does a good job of hiding the servername, and some regulatory specs require that you do so. If someone knows the machine name they may have a slightly better chance to attacking it. So there could be some value to to completely hiding the server name.

    However, the risk is very minimal IMHO. There's not much you can do with a name in most situations that you can't do with an IP address, especially in a server farm where the server can't be directly accessed from the web. That's a call that you will need to make in your environment.

Comments have been disabled for this content.