0. Download
Click here to download the current english version.
 
1. License information
SanSites is freeware. You may copy it, install it and use it as you want. You may not sell it, sell any modified version of it or sell any software containing it (in whatever functionality). You may modify it as long as you mark the modified versions as such and include this license information.
SanSites comes the way it is with no obligation for support, updates or anything else. There is no guarantee for it to work properly and no responsibility will be taken for whatever damage is being done by using it in whatever way.
If you like SanSites, we’d appreciate if you donate an amount of your choice to sales@sansoft.biz using Paypal (www.paypal.com).
SanSites is © 2004 by SanSoft
 
2. General information
The Microsoft Internet Information Service (IIS) has a severe built-in limitation when running on a Windows client version (such as Windows XP Professional): It prevents you from having more than one web site at a time. This means that if you have two or more domains you will get some problems trying to host them on an IIS running on a windows client version.
SanSites is one out of several tools providing a solution for this limitation. The “technical information” section serves as a guide over the different approaches and explains how SanSites works and why it is different (and, of course, better!) than the other tools. Have a look and if you like it, download it – SanSites is freeware!
 
3. Technical information
An IIS running on a Windows client version allows you to add as many virtual directories as you want, but it will not allow you to add any new web sites. This particularly is a problem if you want to host multiple domains (i.e. “www.domain1.net” and “www.domain2.net” or “shop.domain1.net”) because installing them in virtual directories will cause you, as the name implies, to access them as subdirectories (i.e. www.domain1.net/www.domain1.net/index.htm).
There are several solutions to solve this problem. The one that Microsoft suggests is to use a Windows server version instead of a client version (what is the reason for the built-in limitation). Unfortunately not everyone can afford or wants to maintain such a server version, therefore this “solution” is out of question here.
Another solution is to use a Windows client version but not to run the (included) “limited” IIS and install another (free) web server (like Apache or Cassini) instead. But again not everybody is willing to learn how to install, configure and maintain completely new software and, even more important, you can not be sure that these web servers will offer the same functionality as the IIS does (especially running ASP or ASP.NET applications might cause serious problems), so this solution will not be observed any further here, too.
What will be observed any further now are solutions that allow you to host multiple domains on an IIS running on a Windows client version, and as far as we know, there are currently four approaches to such a solution:
1. If you don’t mind the subdirectory in your URL you can create a simple script file (most likely an ASP) reading the specified host (from the header of the http request) and redirecting to the respecting subdirectory. In its most simple way this will look about like this:
If Request.ServerVariables("SERVER_NAME") = "www.domain1.net" Then
    Response.Redirect "www.domain1.net/www.domain1.net"
End If
    If you search the internet you might find many examples and maybe even tools which all do what the above example does.
The good thing about this solution is that it needs only little work and allows using all the features of the IIS. The bad thing is that visitors will see that you are using a subdirectory and that specifying a link to a special page on your web site (i.e. your download page) will have to include the subdirectory (i.e. www.domain1.net/www.domain1.net/downloads.htm) thus making the link very long and hard to read, so this solution will not satisfy everyone.
2. If you like to set up multiple web sites but only need to run one at a time you can add new web sites to the IIS programmatically (search the internet for examples) – and if you don’t want to do this yourself, there are even some tools available on the internet that will do it for you (like IISAdmin). After you added your web sites you can see and configure them in the IIS snap-in (!) like you are used to, but unfortunately you can run (start) only ONE at a time, so this solution is a good thing for people who need to test something (like developers), but of course this will not help you if you really want to put multiple domains online.
3. Another solution is to make an internal redirection, either by writing a script similar to solution 1 but using the “Server.Transfer” method or by using an ISAPI filter. Either way you can read the specified host (from the header of the http request) and redirect inside the IIS to a specific page. There are some tools available on the internet that are easy to use and do exactly that (like MultiSite), but unfortunately internal redirections may cause unexpected behavior when calling pages who can not deal with that (the most famous example being ASP.NET applications where the requested .aspx page may be where ever you want but the bin folder and the web.config file will still be searched in the wwwroot folder - thus making the whole redirection useless).
So internal redirections are a good thing for web sites using only basic file types (like .htm or .jpg), but will not work when using more complex web applications like ASP.NET. (And by the way: Our experience is that stability is a serious issue with ISAPI filtering often causing the IIS to completely stop!)
4. So solution 3 might always cause unexpected behavior because the consequences of the internal redirections are hard to foresee. And solution 2 has a limitation that will make it impossible to run two web sites at the same time. Only solution 1 provides the full functionality and expected stability, but because of the subdirectory issue this solution isn’t perfect either. And this is where SanSites comes in: SanSites takes the advantages of solution 1 and eliminates the subdirectory issue! How is this being done?
SanSites works as a web server, but in contrary to real web servers (like IIS, Apache, Cassini) SanSites only redirects the requests from clients to real web servers who in fact process them, then takes their responses and redirects them back to the clients. Although this resembles more the functionality of a proxy server, there is one major difference: SanSites modifies the request and response headers so that (simply spoken) a request for domain www.domain1.net is being sent to www.domain1.net/www.domain1.net and the response from www.domain1.net/www.domain1.net seems to come from www.domain1.net. The following chart helps to understand this process:
 
 
So after installing SanSites you will have the full functionality and expected stability of solution 1 without the subdirectory issue. Since the installation only takes about a minute and SanSites doesn’t need any extra configuration work you get rid of the one-web-site-limitation of the IIS running on a Windows client version without having to buy an expensive Windows server version or spend much time installing and configuring a new web server software. And because SanSites uses an external redirection and not an internal one (like an ISAPI filter) it is ensured that everything working within the IIS will also work using SanSites. (And of course, since you are only using the provided functionality of the IIS, this is all perfectly legal.)
Having praised SanSites that much there needs to be added that the insurance (that “everything working within the IIS will also work using SanSites”) is theoretical only. But testing so far proved that the download of different files (.htm, .jpg, .gif, .mp3, .pdf, .swf, .zip) as well as large files (>650MB) is possible, that “Integrated Windows authentication” works and that ASP and ASP.NET applications run perfectly. Since these were the goals when developing SanSites, testing was terminated - therefore there is no guarantee that other more complex tasks (like SSL?) will currently work. But because of SanSites’ design it SHOULD work using the correct header modifications; so if you find such a problem please contact us and we might try to adjust the header modifications to match the new tasks.
After all, SanSites is doing its job and has a nice performance – and software that does its job with a nice performance is basically good software, isn’t it?
 
4. Setup information
We are assuming that you are using Windows XP Professional and have a standard installation of the IIS - if this is not the case, you may need to adapt this setup information to your operating system and web server installation. We are also assuming that you already registered your domains and configured the name servers to point to your web server – or that you know how to do it later.
Please note that our screenshots may look different from what you see on your display (as they were taken on a German version of Windows XP Professional).
In order for SanSites to work, you need to switch the IIS to listen on port 8080 instead of port 80. Then you have to install SanSites who will now listen on port 80 (and redirect all http traffic to and from port 8080).
In order to do that, perform the following steps:
1. Open the “Control Panel” and navigate to “Administrative Tools”, “Internet Information Services”.
 
 
2. In the new window expand “local computer”, “Web Sites”, then right-click on the “Default Web Site” and select “Properties”.
3. Select the tab “Web Site”, change the value for “TCP Port” from 80 to 8080 and click “OK”. If you are asked if the IIS should be restarted, say “Yes”. Close all open windows.
 
 
4. Download and run the SanSites setup file and follow the installation wizard.
5. You can now set up any domains you want by adding virtual directories to your IIS default web site. Make sure the directory name exactly matches the domain name (i.e. www.domain1.net or shop.domain1.net). Don’t forget to adjust all other IIS settings (like the default document).
 
 
6. NOTE: Because of the redirection the IIS thinks that all requests are coming from and going to the localhost, thus using standard methods to return the clients IP address or the host name will fail. So in case you are using such methods you need to replace them with custom methods returning the correct information added to the headers by SanSites. For ASP and ASP.NET applications examples for such custom methods are included in the file Examples.txt. For other applications similar adjustments have to be made.
7. NOTE: To uninstall simply open the “Control Panel”, navigate to “Add/Remove Software”, select “SanSites” and click “Uninstall”. Then follow steps 1 and 2 and set the value for “TCP Port” back to 80.
 
5. Error finding
There is no error finding section yet, but you may send an email to support@sansoft.biz instead.
 
6. FAQ
There is no FAQ section yet, but you may send an email to support@sansoft.biz instead.
 
7. Technical specification
SanSites runs as a Windows Service and has been developed using C# under Visual Studio .NET 2003. It works as an http web server that redirects incoming requests for domain [x:80] to virtual directory [127.0.0.1:8080/x]. The web server is multi-threaded and uses synchronous socket communication.