It looks entirely like the load balancer’s problem, but you’re sure it’s not. So what gives?

One reason (especially if they’re using an app server like IBM WebSphere) is that the server can be giving you a “there’s no one here by that name” re-direct. Lemme ‘splain.

When a browser makes a request, part of the request is the HTTP header “host:” field. Whatever the client puts in the address bar of their browser is populated into the HTTP host header (regardless if name resolution comes from DNS or a static entry in your “hosts” file).

This host field is relayed, without modification, to the web server. The load balancer typically doesn’t look at this, and certainly doesn’t change it.

A problem can occur if the web server doesn’t know it’s supposed to be serving up the website specified in the “Host:” field. Most web servers are configured to drop to a default document root if it doesn’t have a specific configuration for the “Host:” header. If there is a default, then an HTTP 200 OK response is given and a page delivered.

Some servers, however, will essentially say “There’s no one here by that name”, and do a re-direct to a web site that it is configured for. This is common with certain types of application servers that run their own web servers, and they’re configured for their default hostnames (rather than the domain name of the site).

For instance, let’s say you have three web servers. You give them the hostnames of web1.lbdigest.com, web2.lbdigest.com, and web3.lbdigest.com. A VIP is configured on the load balancer, and DNS is set to point to that virtual IP. The website is advertised as lbdigest.com, so the “Host:” field is populated with “lbdigest.com” when a request is made.

The load balancer accepts the connection, and forwards it to web2.lbdigest.com. The web2.lbdigest.com server sees the “Host:” header as “lbdigest.com”, and says “Woah, I have no idea who lbdigest.com. I only know about web2.lbdigest.com. I’m going to redirect you to web2.lbdigest.com”. An HTTP 302 response is given, which tells the client browser to go to web2.lbdigest.com. Unfortunately, there’s no public DNS for this hostname, so the browser gives the rather informative error “website cannot be displayed”.

If there’s no public DNS record for web2.lbdigest.com, or if there’s no public network access directly to the web2 server, you’ll get “Website cannot be displayed” error in Microsoft IE. Even if you can access the server directly, this bypasses the load balancer and negates it’s purpose. If that server goes down, clients aren’t sent to an available server.

Again, most web servers will handle an unknown “Host:” header by serving up a default page. But some web servers, particularly application web servers, won’t serve up a default page. Somewhere, deep within their configuration files, there’s a field for the hostname of the app server instance. If none is specified, it can default to the system’s host name (which usually doesn’t match the domain name it’s supposed to be serving up).

How To Prove This

The tricky part is proving this to the app server group. This can be done relatively easily with one of the browser header tools, such as IEHTTPHeaders and Firefox Live HTTP Headers. Punch up the website, and you’ll see the 302 come from the server, and you have your proof.

Solution

The fix is pretty easy. Have the application group configure each of their app/web servers to set their configuration files to specify the domain name that the load balancer answers to. Once this is done, the application should respond correctly.

]]> http://lbdigest.com/2008/04/02/theres-no-one-here-by-that-name/feed/ 1