After setting up a new instance of IIS on a Windows 2003 test server I found that I could connect to it via the WAN and other machines on the LAN but the server itself would’t display the new website. Both IE and FireFox displayed “Bad Request (Invalid Hostname)”, with detailed errors displayed I saw HTTP Error code 400 in both browsers.

Searching found a number of discussions about this error message, but many of them either didn’t solve the issue or simply recommended to “start over” with a new instance of IIS and/or a new virtual website within IIS. The only suggestion I found with specific steps detailed (to set IIS headers to default settings and clear custom headers & MIME types) didn’t actually solve the issue, but it did get me to think about the fact that only the local machine saw the error message.

It turns out that in the Properties dialog for the new website I had assigned a specific IP address (i.e.: 10.10.x.x), instead of leaving the default “(All Unassigned)” setting (see image below with default setting). As a result of the server being multi-homed, using both “localhost” and 127.0.0.1 to access the website in a browser allowed the server to locate itself without using DNS, but those addresses came across a different NIC than the one IIS was assigned to and IIS wouldn’t respond with anything useful (like a web page) to those IPs.

The solutions are simple, but which one is correct depends on the LAN’s configuration or the server being multi-homed (more than one active NIC in the server):

• Use the default setting “(All Unassigned)” in the IIS website properties box for “IP Address:” - this works in single- and multi-NIC servers, but may cause issues on networks with multiple subnets if a site shouldn’t be available to all of them.
• Access the website via the computername (i.e.: http://TEST_SERVER/) while a specific IP Address and not “(All Unassigned)” is selected - if DNS or WINS is running on the local LAN or domain. However, it can still fail if the server has multiple NICs and routes to the wrong one. To get the computername type “echo %computername%” at a command prompt.
• Configure the local HOSTS file (usually %systemroot%\system32\drivers\etc\, “HOSTS” with no file extension) to target the correct correct local machine IP for IIS to work. Note: this may break other services or server daemons running on the box in question, so this is only a brute force option.

6 Responses to “Fixing a “Bad Request (Invalid Hostname)” - 400 Error, on Windows IIS Server”

1. Mike Buday, on January 13th, 2006 at 1:27 pm, said:
   

   If the above doesn’t resolve the IIS error, or you have other IIS errors, here’s a post with great IIS debugging info: http://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Basics_of_IIS6_Troubleshooting.aspx

2. Clive Campbell, on September 12th, 2006 at 10:23 pm, said:
   

   Very useful posting - thank you.
   I had the opposite problem on a secure site under IIS 6.0 on Windows Small Business server 2003. LAN was OK but WAN had this problem.
   Using “all unassigned” instead of actual IP address of site on multi IP address site server has removed the WAN problem.

   Regards
   Clive Campbell

3. Drew Nichols, on February 7th, 2007 at 11:03 am, said:
   

   Too bad Mosso doesn’t know about this, or it doesn’t apply to them because of the cluster!

4. Angelle Adlay, on January 14th, 2008 at 12:57 pm, said:
   

   Hi,

   Thank you so much for the solution, setting IP Address to “allUnassiegned”. It worked. God bless you; I’ve been at this for weeks.

   Now I can start do real work.

   Cheers

   Angelle Adlay

5. Mehdi haeri, on January 27th, 2008 at 12:03 am, said:
   

   The Response is in the Host Header Value
   Delete It If You Fill A Value
   This Work Fine

6. Dan Burgess, on March 20th, 2008 at 2:43 pm, said:
   

   Thanks a ton. I was researching this for a while. I flipped the setting to “All Unassigned” and Report Server’s web page came up like a champ. Greatly appreciated!

Comment on this post below

You can leave a response, or trackback from your own site.