l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
November 4: Social gathering
Next Installfest:
TBD
Latest News:
Oct. 24: LUGOD election season has begun!
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



> ---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.
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
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:
EDGE Tech Corp.
For donating some give-aways for our meetings.