Re: Decision about Host?

Your comments ares consistent with my intent.  However, it may have a 
bug, or an unintended limitation: lots of servers names start with 
"www", so rule (2) would require them to be semantically the same, 
which is not what I think people want:  they want a server to be able 
to support both "www.foo.com" and "www.bar.com".

I was thinking of the following example:

Suppose there is a client who accesses URL "http://www.a/" and whose 
search rules are "pa.dec.com;src.dec.com;dec.com", and suppose there is 
a server that serves "www.a.src.dec.com" and "www.b.pa.dec.com" (which 
are supposed to be distinct) and that there is no server named 
"www.a.pa.com" or "www.b.src.com".  What DNS names would that server 
have to think it served?  I was thinking that they would be
	www.a
	www.a.src
	www.a.src.dec.com
	www.b
	www.b.pa
	www.b.pa.dec.com
where the first three and the last three referred to distinct local 
trees of Web resources. And I think this particular scheme is 
unambiguous, and would continue to be so if all clients had those search rules.

As I look at it, I realize that it can be shortened to
	www.a.src.dec.com
	www.b.pa.dec.com
Either way will work as long as *every* client's search rules are 
configured so that it will never send "www" as the "Host:" value to 
this server. The first way does a simple match on "Host:" value, the 
seond does a prefix match.  This will work as long as no client has 
"a.src.dec.com" or "b.pa.dec.com" as a search rule.

In order to make this work universally, it says that *no* client can be 
configured to have a search rule that is the non-shared suffix of *any* 
server's supported FQDNs.  This would be a hard constraint to check or 
express. And while it might be sufficient, it's not clear that it is 
the minimum restriction on the search rules needed to guarantee 
non-ambiguity. Uggh,

Hence, I propose the following:
1) PQDNs are allowed
2) if a server recieves a "Host:" that contains a PQDN that is a prefix 
of more than one of the FQDNs it supports, then it returns "400 Bad 
Request". Otherwise, it recognizes the PQDN as referring to the FQDN of 
which it is the prefix.
3) configuration rules to guarantee that no client ever gets a 400 
response are beyond the scope of the spec.

Paul

----------
] From: Jeffrey Mogul  <mogul@pa.dec.com>
] To: Paul Leach
] Cc:  <netmail!http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
] Subject: Re: Decision about Host?
] Date: Thursday, October 05, 1995 1:17PM
]
] 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 18:22:56 UTC