ColdFusion Muse

IIS 7 and the Web.config File

Mark Kruger January 6, 2011 6:42 PM Hosting and Networking Comments (5)

If you are new to IIS 7 you may not know about the Web.config file. This file acquires its initial properties from the global settings that you set at the server level (as opposed to the site level). If you make certain changes to the global settings (like adding a default doc for example) then a new web.config file is automatically created and put in the root of each site you add. Or possibly it's created when you fiddle with the site specific settings and deviate from the global settings. I'm not clear on when it is and is not created. But you can of course create one for yourself. The format looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<defaultDocument>
<files>
<clear />
<add value="index.cfm" />
<add value="index.html" />
<add value="Default.htm" />
<add value="Default.asp" />
<add value="index.htm" />
<add value="iisstart.htm" />
<add value="default.aspx" />
</files>
</defaultDocument>
<directoryBrowse enabled="false" />
</system.webServer>

</configuration>
This one simply specifies a few things for this site - the list of potential default docs and whether directory browsing is enabled or not.

An important note (and something I just ran into today) is that this file is pretty specific to the server you are on. It's not a great idea to put this file in your source code repository and have it deployed for example. In our case we deployed the production file to staging. The production file had a specific line in it from the production web server that implemented DotNetDefender (a nice URL scoping filter that helps weed out DOS, buffer overruns and other pernicious attacks). Our dev site (which is all internal to our network) doesn't have this filter installed. When the web.config file was deployed it resulted in our requests all returning 404 errors. It took about 20 minutes of head scratching before I figured out what was going on. Imagine how panicked we would be if we had deployed a dev web.config file to production with the same result (yikes!).

Anyway, like many site specific files (ini files, sometimes Application.cfm or .cfc files etc) you should carefully consider whether you want this particular file to become a part of the "official" code base.

Finally, there are many things you can do with the web.config file - much like the venerable httpd.conf file. You can add rules for mod_rewrite, add specific redirects, control permissions for folders etc. It's a very versatile new tool in the IIS arsenal. And yes Wil, you can manipulate this and all other IIS properties from the command line. Indeed, with Win08r2 Core you don't even need a desktop to be running at all. How does that grab you?

  • Share:

5 Comments

  • Craig M. Rosenblum's Gravatar
    Posted By
    Craig M. Rosenblum | 1/7/11 12:09 PM
    Yes, I agree, this is a great new innovation in IIS7. Would also be nice if they also simplified the interface and lingo, to be more like apache. For some reason they seem to enjoy over-complication.
  • Mark A Kruger's Gravatar
    Posted By
    Mark A Kruger | 1/7/11 1:25 PM
    @craig,

    I know that apache loyalists will rake me over the coals for this, but I wish there was something like IIS manager for apache. I hate hate hate manual configuration of text files using VI (gah!!). Sorry - I know that's heresy :)

    -Mark
  • Julian Halliwell's Gravatar
    Posted By
    Julian Halliwell | 1/9/11 6:55 AM
    Agree with all your points about the benefits and dangers of web.config files, Mark. I do generally consider them part of the code base because, as you say, they can contain specific rewrite rules, without which the app/site might not work.

    To avoid the type of issue you mention we try to keep our dev and production environments indentical so the config will work in either context. It does need careful checking though, so thanks for drawing attention to it.
  • Mark Kruger's Gravatar
    Posted By
    Mark Kruger | 1/9/11 5:50 PM
    @Julian,

    I agree about dev and live but we support something on the order of 80 different dev environments. At least some of them are going to have to share space on a server so it's not always possible :)

    -Mark
  • snake's Gravatar
    Posted By
    snake | 3/5/12 5:44 PM
    Snake agrees, Apache needs a decent UI, but the purists are usually against such things so it will never happen.