Re: Decision about Host?

I've skipped a few of the messages in this thread, so perhaps this
is repetitive.

Paul writes:
    It occurs to me, that if the client and server have exactly the
    same domain search list, then there shouldn't be any problem using
    the relative domain names, and that this may often be true in the
    case that is most important -- within a corporate environment.

    This would mean that a server has to know all the fully and
    partially qualified names that it is trying to serve -- not a big
    deal if it could be configured to know more than one FQDN.

In other words: even if the client does not know the FQDN, presumably
the fact that it has opened a TCP connection with a given server
means that the PQDN provided is a prefix of one of the server's
FQDNs, or that the connection was made in error.  However, this
kind of error (connecting to the wrong host) seems rather unlikely,
doesn't it?

    Hence, I would support either:  a) require FQDN or b) require FQDN
    or PQDN when PQDN is administratively known to be unambiguous for
    all servers reachable by PQDN.

How about
	(1) clients SHOULD transmit the FQDN
	(2) the HTTP 1.x protocol DOES NOT SUPPORT server hosts with
	semantically different bindings to multiple FQDNs
	if any pair of those FQDNs share a common prefix.
	(3) server administrators SHOULD NOT configure servers
	in violation of rule (2).

Rule (2), in effect, says that you can have a single host serve
"a.dec.com" and "b.dec.com" as completely different servers.
It also implies that you can have "a.dec.com" and "a.pa.dec.com"
and "a.digital.com" as long as they all are intended to mean
the same thing.  It says that you cannot serve "c.pa.dec.com" and
"c.digital.com" from the same host if these are are meant to
be semantically different (that is, if "http://c.pa.dec.com" is
supposed to return different data than "http://c.digital.com").

I suppose if a client managed to connect to "a.sgi.com" when it
was trying to retrieve "http://a.digital.com" (but using the PQDN
URL "http://a/"), then this mistake could result in an undetected
error.  But it already would in HTTP 1.0, so this shouldn't be a
big deal.

-Jeff

Received on Thursday, 5 October 1995 13:42:12 UTC