Data Center QoS equipment breaking http 1.1?

Ivan Pepelnjak ip at
Sat Aug 1 03:11:10 CDT 2009

Facts first: name-based virtual hosts depend on the HOST header in the
HTTP/1.1 request to select the virtual web server.

> I poured over my configs (I've done this config countless 
> times), and saw this in the apache docs:
> " Some operating systems and network equipment implement 
> bandwidth management techniques that cannot differentiate 
> between hosts unless they are on separate IP addresses."

Thanslated into networking engineerese: since the QoS equipment (including
routers unless you use HTTB NBAR) cannot peer into contents of the TCP
session, it cannot find the HOST header and thus cannot decide which virtual
host the traffic belongs to, making it impossible to enforce
per-virtual-host QoS policies.

> So, I installed lynx on the server, and sure enough, it 
> worked perfectly fine there, just not from anywhere outside 
> eSecuredata's network that I could see.
> Can anyone shed any light on this particular practice, of 
> this company in particular?

What you're experiencing usually means only one thing: they're using a box
that messes with HTTP headers. It could be a misconfigured DPI box, a
transparent (broken) HTTP proxy or a custom-developed "wizardry".

Configure the Apache logs ( to
log the virtual host name in the HTTP request (the %{host}i directive) or
use Wireshark on your client and the server to inspect it. If you find out
they're messing with the HOST header (as suspected) switch the provider


More information about the NANOG mailing list