- From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
- Date: Sun, 11 May 1997 18:56:55 -0700
- To: Benjamin Franz <snowhare@netimages.com>
- Cc: http-wg@cuckoo.hpl.hp.com
>How do you intend to distinguish 'www.nihongo.org' from
>'www.netimages.com' on my server? They share the same IP address, the same
>host name, and are completely unrelated. If I type 'http://www' on my
>browser, I *WILL* connect (since I am inside the network) - but the server
>will and *can* have no idea which of 6 different servers I *meant* to
>access - a problem that will worsen with time. FQDNs are a sine qua non
>of using the Host: header..
Excuse me, but just how is the browser going to handle it then?
The browser can either attempt to use the URL or reject the URL.
Neither decision is applicable to HTTP, since this is before HTTP
is even used. In fact, since it isn't even possible to know if a
host is fully-qualified until the lookup is made, how is the browser
going to comply with this new requirement?
In current practice, the last client in the request chain will just
do a DNS lookup on the host and use the first entry returned. If the
host was ambiguous, doing a DNS lookup will not make it any less ambiguous.
Choosing the first alias name from the list and using that for the
Host field would be an arbitrary choice -- no better (and often worse)
than just sending the ambiguous name to the server, at which point the
server could handle it in an intelligent fashion.
Furthermore, since doing a DNS lookup (and even having access to DNS)
is not necessary for an HTTP client using a proxy, requiring a DNS
lookup is out of the question.
The answer to your problem is the same I gave last time this question was
discussed: if you don't want ambiguous results, don't use ambiguous URLs.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92697-3425 fax:+1(714)824-1715
http://www.ics.uci.edu/~fielding/
Received on Sunday, 11 May 1997 19:07:22 UTC