Re: Decision about Host?

It strikes me that this problem has been dealt with before when mail
went to domain-based addressing.  I did a quick check, and RFC822
takes one of the approaches advocated here - that domain fragments can
be used so long as the two hosts agree on how to resolve them.
However, RFC1123 changes this, requiring fqdn in all cases (both SMTP
commands and mail headers) so that forwarding can be done without the
forwarder having to muck with the headers in question.

Since mail forwarding seems to be similar to proxies, this would imply
that the correct solution - as demonstrated by the experience with
mail - is:

I) The value of the Host header is the fully-qualified domain name.

However, there might be better solutions, and servers will still have
to deal with broken implementations, so I'd suggest relaxing this
slightly:

II.a) The value of the Host header should be the fully qualified domain name.

II. b) A server receiving a domain fragment may handle it in any manner
desired - as if Host were missing; as an error; or by offering an
appropriate 300 alternative.

On the other hand, I get the feeling that some people feel that Host
should reflect what the user typed, and nothing else. This means we
get:

III) The value of the Host header may be an fqdn, IP address or domain
fragment.

And the onus of resolving it is on the server, and could well result
in "misfetches" as user at foo.dom asks for "www", which is being
served by dual-homed isp.dom, which is also serving www.isp.dom, so
they get www.isp.dom instead of www.foo.dom. Personally, I don't like
this one.

If the client is allowed to send domain fragments, a decision about
whether a proxy is allowed to rewrite them needs to be made. If option
I or III is taken, this doesn't matter.

	<mike

Received on Friday, 6 October 1995 11:13:32 UTC