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 19 00:29

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

On Monday, November 18, 2002, at 02:17  PM, Ken Bloom wrote:

>> 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.

That's true, but it's not the web browser's fault. How is the web 
browser supposed to know that my is really my.ucdavis.edu (as Sam points 
out). That's what you get with virtual hosts: the browser user should 
just bunker down and type my.ucdavis.edu if he expects that to be in the 
Host header field.


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.