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 14:22

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 Sat, Nov 16, 2002 at 10:48:22PM -0800, Ken Bloom wrote:
> > Date: Thu, 14 Nov 2002 17:40:45 -0800
> > To: vox-tech@lists.lugod.org
> > Subject: Re: [vox-tech] Omsoft transparent HTTP proxy
> > From: Henry House <hajhouse@houseag.com>
> > Reply-To: vox-tech@lists.lugod.org
> > 
> > 
> > --liOOAslEiF7prFVr
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> > 
> > On Thu, Nov 14, 2002 at 12:56:37PM -0800, Rod Roark wrote:
> > > Well I know the web browser transmits the hostname that you
> > > requested along with the rest of the URL.  This is required
> > > in order for name-based virtual hosting to work.
> > >=20
> > > So it appears your browser does not fill in a missing domain
> > > in the passed hostname.  Whether it should, I'm not sure.
> > > You might try some different browsers and see if they do it.
> > 
> > If it does, that behavior is broken and non-standard. The URL http://my (yo=
> > ur
> > example) should resolve to the machine 'my' in the local network. This might
> > be 'my.internal' if you have a private network called internal, or
> > 'my.ucdavis.edu' if your search domain (configured in /etc/resolv.conf) is
> > ucdavis.edu.
> > 
> > I have often been annoyed by web browsers that automatically convert
> > single-name URLs into www.{name}.com form, without even checking for the
> > existance of a machine {name} first. Lynx gets it right, checking first, th=
> > en
> > trying name expansions. Konqueror does not. Why don't you see if lynx behav=
> > es
> > properly for you?
> Lynx behaves properly when used from pc131.cs.ucdavis.edu (one of the 
> new PCs installed this month in the CSIF labs - the older PCs don't have 
> lynx installed). When used from my own computer, I get the http 503 
> error caused by Omsoft's proxy. (By the way, the error 
> page tells me that the proxy is running Squid/2.4.STABLE7)
> Rod's suggestion though is right: I tested various requests using 
> `netcat my 80`
> ====
> GET / HTTP/1.1
> returned correct data
> ====
> GET / HTTP/1.1
> Host: my.ucdavis.edu
> returned correct data
> ====
> GET / HTTP/1.1
> Host: my
> returned the error. 
> 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)
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. 

Samuel Merritt
OpenPGP key is at http://meat.andcheese.org/~spam/spam_at_andcheese_dot_org.asc
Information about PGP can be found at http://www.mindspring.com/~aegreene/pgp/

Attachment: pgp00008.pgp
Description: PGP signature

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:
EDGE Tech Corp.
For donating some give-aways for our meetings.