Re: Decision about Host?

Paul Hoffman writes:
> This is true for present software: the server software had to be listening
> to a particular port in order to even get the "Host" header, or anything
> for that matter. My thought was, in the future, one copy of a server might
> be watching more than one port number for requests. As far as I know, none
> do that now. In that case, it could be useful for the server to know which
> port the request came in on. This seems a bit far-fetched, given that any
> 1.0-speaking client would never tell the server, and thus it would be
> assuming way too much.
This is the pathological case I mentioned, but even this pathological case
needs pathological programmers to not work without port numbers in Host header
field value. In TCP/IP there is no way to listen simultaneously on two ports
on the same socket. The getsockname API call will return the sockaddr_in
structure (containing the port number) even if the programmer was too lousy
to remember the port number to which the socket is bound.
> I think it's probably not worth adding the port for this very small
> potential in the future since it might lead to some ambiguities.
Really not.
> Which reminds me, we should remember in the "Host" wording of the spec that
> there may be an IP address instead of a domain name in the URL. The URL
> spec allows IP addresses in the host part, and some people use them when
> their chosen DNS server is broken. And, I've seen a fair number of
> hard-coded IP addresses in some of the big databases like Yahoo and Lycos.
Agree. (Someone may think, that an IP address is a special case of host name,
but an explicit statement on this is better.)

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Saturday, 7 October 1995 12:50:35 UTC