[vox-tech] Omsoft transparent HTTP proxy

Ken Bloom vox-tech@lists.lugod.org
Mon, 18 Nov 2002 14:17:06 -0800


> ---ORIGINAL MESSAGE--- 
> Date: Sun, 17 Nov 2002 00:43:20 -0800
> From: Samuel Merritt <spam@andcheese.org>
> To: vox-tech@lists.lugod.org
> Subject: Re: [vox-tech] Omsoft transparent HTTP proxy
> Reply-To: vox-tech@lists.lugod.org
> 
> 
> On Sat, Nov 16, 2002 at 10:48:22PM -0800, Ken Bloom wrote:
> > Who's right, and who's wrong? Is the web browser wrong for not expanding
> > the Host header? Or is the proxy wrong for relying on the Host header to
> > resolve IP addresses instead of relying on the IP address that the
> > actual packets are destined for? Or are they both wrong (this could very
> > well be the case)?
> 
> The web browser is right. I think what happens is something like this:
> 
> 1) The browser gets a request from the user for http://my/.
> 2) The browser issues a gethostbyname(my) call.
> 3) The DNS resolver checks its search order, and finds "ucdavis.edu", so
> sends a query to the name server for "my.ucdavis.edu"
> 4) The DNS resolver gets an IP back from the name server.
> 5) gethostbyname(my) returns that IP.
> 
> Notice that the browser doesn't have any idea that "my" is in domain
> ucdavis.edu; the search order information is in /etc/resolv.conf, and
> only the DNS libraries make use of that.
> 
> The proxy is the one screwing things up.
> 
> What the proxy should do:
> 1) Get a request originally destined for IP A.B.C.D, with "Host: my" in
> the header.
> 2) Connect to A.B.C.D, passing the Host header (and any other headers)
> along.
> 3) If the content is in cache, return it from cache rather than
> downloading it again.
> 
> What it does:
> 1) Get a request originally destined for IP A.B.C.D, with "Host: my" in
> the header.
> 2) Look up "my" in the DNS, and fail.
> 3) Ignore the fact that the request was headed for A.B.C.D, and give an
> error message.
> 
> I recommend bugging Omsoft about this; their proxy is clearly broken.
> 

It would seem to me however, that the web browser's behavior is also 
broken, because if my.ucdavis.edu were really virtual hosted, even if 
Omsoft didn't filter HTTP traffic through a transparent proxy, 
then the server hosting my.ucdavis.edu would recieve a header stating 
"Host: my", and be just as confused as Omsoft's proxy.