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:
http://httpd.apache.org/docs/2.2/vhosts/name-based.html
" 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 (http://httpd.apache.org/docs/2.2/logs.html) 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 immediately. Ivan http://www.ioshints.info/about http://blog.ioshints.info/