Re: Claification requested in Host:

On Fri, 14 Feb 1997, Dave Kristol wrote:

> Dah Ming Chiu[SMTP:dahming.chiu@Eng.Sun.COM] (via jg@zorch.w3.org) wrote:
>   > Here is a HTTP 1.1 question for you.  According to the spec 14.23, the
>   > Host field is defined as
>   > 	"Host" ":" host [ ":" port ]
>   > where (in 3.2.2), host is defined as
>   > 	<a legal Internet host domain name or IP address...>
>   > 
>   > The question is whether a single component name consititute a "legal"
>   > Internet host domain name?  For example, a user types in "foo" at his
>   > browser, which runs in domain "xyz.com".  The browser is smart enough
>   > to assume the use wants to talk to "foo.xyz.com", and hence gets the
>   > correct IP address.  But in the HTTP request, the browser sends
>   > 	Host : foo
>   > Does this browser conform to HTTP 1.1?
>   > 
>   > If the answer is yes, there may be a problem with HTTP 1.1, since the
>   > ambiguous host name is not sufficient for virtual host implementation.
>   > 
>   > I suspect the answer is no, in which case that browser is not conformant.
>   > Could make this point clear in your spec?
> 

My interpretation is that the name given in the Host header must uniquely
identify the (potentially virtual) host. Perhaps on an intranet, something
like woodhousegjisf (the WINS name of my workstation at work) would be
adequate, but on the Internet a globally unique name is needed...or is it?
I can iamge a URI scheme that would resolve into ordered triples of the
form

(IP address, host, relativeURI)

In this scenario, thos host part would only have to be unique for the given
IP address.

> RFC 2068 also says:
> 	The Host field value MUST represent the network location of the
> 	origin server or gateway given by the original URL.
> 
> Therefore, my take on this is that, if the URL was
> 	http://foo/bar/bletch
> then
> 	Host: foo
> is correct.  If we're in domain xyz.com, I could live with seeing
> 	Host: foo.xyz.com
> instead.  What would not be acceptable, I think, is if "foo" is
> an alias for abc(.xyz.com), and we get
> 	Host: abc.xyz.com
> or
> 	Host: abc
> 
> That would defeat the whole point of Host, to allow virtual hosts.
> 
> Dave Kristol
> 

I thought the terminology here, "network location" was very well chose,
omitting a it does any mention of how that location is to be interpreted. I
believe we CAN leave this unspecified in HTTP/1.1, but perhaps the point
tht the network location doesn't need to be a domain name should be
clarified. For Host to be at all useful, though, there does need to be a
well-defined mechanism for interpreting the netowk location. I believe this
is properly a URI issue, and the HTTP/1.1 spec should (must?) containa a
pointer to the appropriate document.

Incidentally, does anyone now use Host for non-DNS hostnames? 

---
gjw@wnetc.com    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.

Received on Friday, 14 February 1997 12:23:51 UTC