Redirect causes infinite loop

Have you actually created separate sites for them in IIS? If you haven't, you will see this sort of behaviour.

Yes, there are two sites, example.com and www.example.com.  They both point to the same physical location on the server but are separate sites in IIS.  When I expand the "Sites" folder in the IIS manager, I see example.com and www.example.com.  Changing the HTTP Redirect of example.com also changes it on www.example.com.  They do share an application pool because I do not want example.com to have it's own set of resources.  However, giving www.example.com it's own application pool as a test did not resolve the problem.

What about if you completely remove the application pool from the example.com site?

Also I assume you have correctly configure host headers so the sites are listening on the correct domain - no spelling mistakes etc.!

I'm not sure what you mean by correctly configure host headers.  I just added the two sites and used the IIS manager's HTTP Redirect function to specify a 301 Redirect from example.com to www.example.com.  I can only assume that IIS is passing the header information along properly, but www.example.com is spelled correctly in the HTTP Redirect function if that's what you're suggesting.

Also, I do not know how to remove an Application Pool.  When You view the Basic Settings of the website where Application Pool can be selected, there is no option for no pool, just the standard pools that have been defined plus DefaultAppPool.

As I mentioned, the source of the problem is that when I use IIS's HTTP Redirect on the site example.com, the site www.example.com is also set to do an HTTP redirect (to itself), and this causes an infinite loop.

In followup, when I use IIS's HTTP Redirect, it just configures the web.config for the site, which exists in the site's directory (which is the same for both as per the redirect instructions).  Consequently, that is probably why the other site is also set to redirect, they are both using the same web.config.  I am going to try to set the example.com to a different directory and see if that helps or makes things worse.

That solved the problem, though I don't like this solution.  This requires a useless directory on the server to point example.com to--does anyone have a better solution on how to achieve the same functionality?  I don't think something as simple as combining www and non-www should be this complicated.

I think the problem you've got is that both sites are listening without any form of separation between the two. On each site in IIS, open it up and follow the info in the latter part of http://www.visualwin.com/host-header/ to add the correct host header for that site. For example, on the redirect site, you'd use example.com, and on the main site, you'd configure the header as www.example.com.

That means the sites will only respond to requests pointed at their own host header.

>>> "That solved the problem"
Which method are you talking about here?

Pointing the physical location of example.com to a different location than that of www.example.com.  This allows each site to use a different web.config, therefore when I add a HTTP Redirect to example.com, it does not update the web.config used for www.example.com.  I just don't feel that this is a good solution because it requires a physical folder to exist for a website that will never be used.

Both sites are configured with their respective hostnames in IIS.  The site you gave me is for IIS 5, I am using IIS 6 but I was able to determine the updated notation for IIS6.  They are called Site Bindings.  The Host Name binding for example.com is example.com and for www.example.com it is www.example.com.

Are you sure you're using IIS 6? The site I gave you is for IIS 6, which is what you will find on Windows Server 2003. If you're not actually using that version of IIS (let me know what operating system it is), then it is going to be a different procedure, but as per the question title, you say you have IIS 6 and the link is for IIS 6.

I apologize, I was thinking the new IIS was version 6, it is version 7, we have Windows Server 2008.

I'm just building a Virtual Machine of Server 2008 to check this out in a test environment. I'll get back to you as soon as I can.

This one hasn't come up for me yet in a VM - I've set up a redirect using two sites just fine.
Have you found any more yourself?

Every site I configure suffers from this problem.  It occurs when you have two sites that point to the same physical location on the server.  When they both point to the same physical location, they use the same web.config.  The web.config handles redirect, so using the IIS administration interface to enable redirect from one site to another will also set the latter to do redirect (because all IIS does is update the web.config, which both sites use) and therefore causes an infinite loop when accessing the latter site.  I always setup a www.example.com and an example.com and redirect example.com to www.example.com.  If I point both of these sites to the same physical location, then setting the redirection on example.com also sets it on www.example.com.  The only way I currently know to solve this is to not have them both at the same physical location, which I achieve by having a www folder in the site name folder under C:\inetpub.  The physical location for www.example.cmo is C:\inetpub\example.com\www and the physical location for example.com is C:\inetpub\example.com.  This sets the web.config for example.com in the root site directory and the web.config for www.example.com in the www directory.  I feel this is an inadequate solution as it shouldn't matter where example.com is physically located because the directory is never served due to the redirect.

Thanks for looking into it for me.  I'll give you the points anyway because you put forth some effort.  It's a bit of a pain in the behind, but I'll live with it for now.

I can't really consider it complete because it's a bug we can't do anything for.

Thanks anyway, and sorry I wasn't able to track the issue down... it's probably just one of those bugs or design faults which you come across from time to time! :-)