On Monday, November 18, 2002, at 02:17 PM, Ken Bloom wrote:
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.---ORIGINAL MESSAGE--- Date: Sun, 17 Nov 2002 00:43:20 -0800 From: Samuel Merritt <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: [vox-tech] Omsoft transparent HTTP proxy Reply-To: [EMAIL PROTECTED]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 expandingThe web browser is right. I think what happens is something like this:
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)?
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.
-Micah
_______________________________________________
vox-tech mailing list
[EMAIL PROTECTED]
http://lists.lugod.org/mailman/listinfo/vox-tech
