[vox-tech] Omsoft transparent HTTP proxy

Ken Bloom vox-tech@lists.lugod.org
Sat, 16 Nov 2002 22:48:22 -0800


> ---ORIGINAL MESSAGE--- 
> 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)?