l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Nov 18 15:10

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Omsoft transparent HTTP proxy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Omsoft transparent HTTP proxy

> 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.
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.