IIS7 - Configuration & Scripting

Re: Wildcard host header support

TCost — Mon, 05 Oct 2009 16:39:03 GMT

I just wanted to add my support for this feature as well. It is going to become a larger and larger issue as more sites offer increased personalization options. Many, if not most, of the DNS providers allow for easy DNS wild cards. It is a shame that you then get stuck with hacks on the IIS side.

Fortunately I only have one site that requires wild card sub-domains so far, so I'm good for now. However, I fear the second site that needs this is only a couple months away so I'll need a new solution very soon.

Re: Wildcard host header support

AJStevens — Tue, 21 Jul 2009 14:53:27 GMT

I'm now using this rule:

RewriteEngine on

# subdomains subdomain.domain.com to www.domain.com for futher processing

RewriteCond %{HTTPS} (on)?
RewriteCond %{HTTP_HOST} ^(?!www\.)[^.]+\.([^.]+\.[^.]{2,3}(?:\.[^.]{2,3})?)$ [NC]
RewriteRule (.*) http(?%1s)://www.%2/$1 [P,NC,QSA]

and I'm using $_SERVER['HTTP_X_FORWARDED_HOST'] in my php page, which returns subdomain.mydomain.com you can of course then trim this down to just subdomain for use in your code.

I'm waiting on my host to apply it to a .htaccess file in the Default Website.

Re: Wildcard host header support

AJStevens — Thu, 09 Jul 2009 16:06:47 GMT

I've read about this online, as I want to do a simliar thing.

The problem with the "IP" solution is it will only work for one site, on one IIS install, AND someone could register a dodgy domain name and point it to your IP and they'd get your website.

What I have come up with (and waiting on the tests to confirm) is a workaround using ISAPI_Rewrite (which I suspect some of you are using anyway and have a .htaccess file with rules).

Now, my solution is to put a .htaccess file in the root folder of the Default website, something like (might need some tweaking):

RewriteEngine on

RewriteCond %{HTTPS} (on)?
RewriteCond %{HTTP_HOST} ^(?!(?:www))([^.]+)\.([^.]+\.[^.]+)$ [NC]
RewriteRule ^([^.]+)?$ http(?%1s)://www.%3/(?1$1) [NC,P,QSA]

Now, not forgetting your * DNS A record. What will happen is a user goes to whatever.mydomain.com and it will go to the IIS server, fail to find a match Host Header wise and will instead return the default website ("Under Construction" page), except with that .htaccess file and ISAPI-Rewrite it won't display the "Under Construction" page, as it will run this rule in the .htaccess file and instead pull in the equivalent from www.mydomain.com where more than likely you will have your actual .htaccess file in the root of your www website and where now you can not only specify rules for your www.domain.com but anything.yourdomain.com

Most commonly you'll want something that does http://username.mydomain.com to pull in data from www.mydomain.com/users.php?user=username for example.

If you don't have a .htaccess file with rules, then you'll just get your www.mydomain.com website but as subdomain.mydomain.com instead.

Of course if you own the server (VPS or dedicated) you can tweak this "main" rule even more, but that was a generic one I hope shared hosting IIS companies could incorporate. Perhaps with a tagline of "Dynamic Subdomains".

Re: Wildcard host header support

kipusoep — Wed, 27 May 2009 09:42:42 GMT

I really do not understand why this feature / must-have is still being dropped... Come on, it shouldn't be that much work for the IIS team, right? But it would help A LOT...

Re: Wildcard host header support

lmeyers — Tue, 05 Feb 2008 02:49:37 GMT

We are hosting a couple instances of DNN each with multiple portals. Each instance is setup on distinct IP as default web site. We let DNN figure out which portal to serve up based upon the subdomain(s)--DNN supports multiple aliases per portal. We also use the host file to create internal shortcut mappings to specific IP and again let DNN work out the intended portal site using alias.

Re: Wildcard host header support

aspcode.net — Mon, 01 Oct 2007 06:46:16 GMT

As Tomas says:
" is to get a dedicated IP address and route *.example.com to this IP address"

yes. That's the dns part. Then in IIS you create a site with NO host header ( = the default website) for that IP. This indeed works - I have a few weeks ago created such a beast - but the consequences are:

(since it relies on the default website per ip)

1. I can just have one "wildcard subdomain site" per IP (I can have additional regular hostheader specified sites on the same ip, yes, but of course just one "default" website)

2. The risk of being "hijacked". Actually happened to my site. Serverside I did some parsing to get the subdomain part out and rewrote the url <user>.domain.com -> /user.aspx?id=<user>

However I never verified that the MAIN domain part was indeed mine. What can happen:

<user>.DIRTYDOMAINNAME.com -> /user.aspx?id=<user>

If someone buys a "dirtyname" domain and simply points it to *your* IP.
Result: a duplicate of your site content is being served (still from your very own server) but under a nasty domain name. Which might be a problem...

What happened to me and my brand new site was that the guy owning the other domain had misconfigured a DNS entry (and pointed a subdomain host of it to my ip).
It was innocent but still...

Personally I really think this should get prioritized by IIS team (i.e being able to specify wildcard in hostheader) - while not being a showstopper for me, it sure is one of these things making you look towards Apache/Mod_AspDotNet

Re: Wildcard host header support

steve schofield — Sat, 29 Sep 2007 13:46:42 GMT

If IIS doesn't fit your needs, use Apache. It's about the solution, not the technology. There are a few ways to do it in IIS I can think of off-hand.

1) Create a host-header for each user

2) Create a single site, use www.isapirewrite.com (3rd party rewrite tool) or something similar to redirect to a each users folder.

3) Write your own HTTP Module that rewrites the URL with ASP.NET.

http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx

http://weblogs.asp.net/scottgu/archive/2006/01/18/435870.aspx

I would probably recommend option #3 if you have ASP.NET developers, otherwise #2 is probably a nice clean solution. You set a wildcard DNS entry, create your folders then have one httpd.ini file to manage.

Re: Wildcard host header support

ooswald — Sat, 29 Sep 2007 09:07:08 GMT

it's a pain that today IIS still doesn't support wildcard host header names. because of this, we can't provide our 12'000+ users with their proper subdomain on our service (username.mydomain.com). instead of they get http://mydomain.com/users/username

no, it's neither a DNS issue nor a "get your own ip" thing. we have one single ip for historical reasons and we're running a couple of websites on it.

is there a isapi filter that solves this matter? no just a simple redirect, but a way that permits us to know the original hostname from within asp.net. wouldn't be a problem with apache, but IIS seems to be stuck back in the 90ies.

Re: Wildcard host header support

thomad — Thu, 12 Apr 2007 06:00:37 GMT

Net_Srak,

We heard this request a couple of times during the last years. Unfortunately it never never made the top priority list. We are close to the finish line with IIS7 - the last small features go in as we speak, i.e. wildcard domain names won't make it into IIS7. The only way to do this (as far as I see it) is to get a dedicated IP address and route *.example.com to this IP address.

Sorry,

Re: Wildcard host header support

qbernard — Wed, 11 Apr 2007 09:24:10 GMT

Yeah, keyword - nice to have. I'm sure MS heard your feedback here. As of now, IIS 7 don't support this, it is up to the team to decide, if you have strong support case, I'm sure they will consider in future, etc.

Re: Wildcard host header support

Net_Srak — Mon, 09 Apr 2007 17:46:21 GMT

Well, that is the beauty of a specification. There are no other perspectives than the specification, and it is not part of the specification how the server internally maps a request to a specific website. Remember; if I enter the address http://blabla.example.com/ the headers sent to IIS would be exactly the same even if the server supports wildcard host headers. There will be no difference whatsoever in the action. If I manually has added blabla.example.com to the website or if IIS support *.example.com has no matter for both the user and the specification. It is strictly an internally decision.

If you really believes, that it is part of the specification (where as I would point your attention to the RFC 2616, so you could read for yourself), why would you allow IIS to support multiple host headers? This is not a part of the specification. Having more than one website pr. server isn't either. These are features of the server, which not breaks specification compliance but more the software more attractive. As I said, virtual directories, server includes aren't part of specification either, but they are for sure nice to have - like ASP.NET, which has nothing to do with core HTTP either.

As far as I know, the Apache team is very strict when it come to protocol compliance, and they support it. Unfortunately, Apache is not an option - if it were, I would have made the change long ago. IIS need to support common used features. To emphasize this argument, I know several hosting centers who choose Apache over IIS - not because of cost, they still use Windows - as many of their clients have need for wildcard host headers.

Also note, that you wont have to use this, if IIS implements it.

Re: Wildcard host header support

qbernard — Mon, 09 Apr 2007 03:39:03 GMT

Well, that's your perspective. I think this is the part of how HTTP server process the incoming request, so it should be in the spec.

Re: Wildcard host header support

Net_Srak — Sat, 07 Apr 2007 15:59:49 GMT

But this has nothing to do with specification. It is usability, administration and convenience. The specification includes nothing about multiple host headers (which is possible) or many other of the features supported (scripting, virtual directories and so on).

The HTTP specification describes the rules of the web server to communicate with clients - not how the web server should be made or act internally.

Re: Wildcard host header support

qbernard — Sat, 07 Apr 2007 04:38:02 GMT

Mmm.... pray hard then.
If this is in spec, MS should and will do it.
If it's not... then pray again.

Re: Wildcard host header support

Net_Srak — Fri, 06 Apr 2007 21:44:40 GMT

This issue isn't posted to get temporary and bad fixes. It is raised to give attention to an ongoing problem with the both old IIS versions as well as the newest 7.0. It is brought up in hope for a extension to future versions allowing wildcard hostname as all other webservers.

As of this writing, the amount of registered .com-domains equals nearly 65 million. If we substract broadcast addresses and other network necessities and includes reserved networks, the .com-domains alone would require min. 2-3 % of all IPv4 ranges. This emphasize that it is not and will never be an sollution to have one IP address per website. Not all websites need this feature, but it is waste of IP adresses to just apply them, where better solutions are possible. In addition hereto, the amount of domains in total would easily triple the amount of .com-domains if not more.

My prayer is: The Microsoft IIS development team, please implement proper support for wildcard host headers. It isn't forbidden in any way and it is possible to do while still remaining strict HTTP conformance.

Also i repeat, that this is not a DNS issue. Wildcard host headers also requires the same wilcard A record as the current "solution" does. Therefore this is completely irrelevant for the discussion as well as the solution.

ISAPI-Rewrite offers redirects, but this is not the same as true support. There is a remarkably difference in the advantages gained from pseudo redirect and proper access to correct HTTP_HOST name values and so on. If you call this a solution, a solution could also be to use a different webserver. These are not solutions and does not deal with the reason for IIS not to support something, which is widely used.

Support it. Please!