According to Chuck Shotton:
>
> Relying on something as weak as a domain name for differentiating the roles
> a server is to perform is an extreme hack. There are MUCH better ways to
> accomodate this that won't be subject to the whims, vagueries, and failures
> of DNS. Path arguments, header fields, and any number of other techniques
> can be used already to help a server determine its "role".
Everything you say is true from a technical point of view. However,
the issue here is a political/commercial one. When a company
contracts with a service provider to create a WWW presence they want
the URL for their company to be something like
http://company_name.com/
They don't want the service provider's name in the URL and they don't
want any path or port stuff at the end. It's a PR thing. It may seem
silly but it is important to them. (As you no doubt know there are
lawsuits now over the ownership rights to DNS names.)
On the other hand, the service provider does not want to have to have
a different computer for each client since most clients put minimal
load on a server.
It seems to me that both the desires of the company and the desires of
the service provider are reasonable and it ought to be possible to
accomodate them with a very minor change in the protocol.
John Franks