Subject: Ftp-WG: HOST command and client upgrades

From: "Jan Mikkelsen" <[email-masked]>
Date: Wed, 15 Dec 1999 20:01:14 -0500

David Cridland writes about an "interim" method for handling HOST:
>"If your FTP implementation supports v-hosting, and is not given a HOST
>command to explicitly state the host required, then look in the USER for
>overloading.
>
>"If your FTP implementation supports v-hosting and *is* given a HOST
>directive, and the username given does not exist, see if it's got
>overloading, and discard whatever the potential host part says, and try the
>username again."
>
>What this means, if my brain is actually working, is that the HOST
command -
>which I beleive is the better solution if it were taken up by clients - can
>be worked around given the overloaded USER we've been talking about, and
yet
>we still aim in the right direction. Ultimately, we end up with HOST
support
>in both clients and servers, without any USER overloading.

"If it were taken up by clients" is the crux of the issue.  I agree that
HOST is nice, and is a good way to avoid USER overloading.   However, if we
use USER overloading to get there, what is the benefit of introducing HOST
to replace the functionality which is working using USER overloading?

Once USER overloading is introduced, the incremental benefit of supporting
the HOST command as well seems limited.  It provides a way for the client to
provide potentially conflicting information which the server has to handle,
and clients don't even need to implement the command because USER
overloading is there anyway.

>The only problem is when you've got a user "fish" on a v-host
>"alpha.isp.com", no HOST command, and a user "[email-masked]" on the
>default site. I imagine you'd have to try both, and see which it was by the
>password, something that's been mentioned before here many moons past -
>Stephen Tihor mentioned it, I think.

The basic assumption here is that there is a "default site".

I don't think that default sites need to be considered.  A site running
virtual hosting might not have a default site at all;  it could very well be
an error if no site is specified (this is the HTTP method).  For sites
running n virtual sites, and a single default site (and there can never be
more than one default) could even have one IP address for the n virtual
sites, and one IP address for the default site, and use the destination IP
address of the connection to disambiguate.  Essentially, this boils down to
running a server where a virtual host must be specified by the client, and
one where it doesn't really matter.  They could be provided by the same
process;  it doesn't really matter.

When enough clients are sending the hostname as part of the username the
special IP address for the default site can be turned off, and there is no
need for a "default" site.

As client functionality progresses, the site operator will be able to
measure how many clients are providing the default hostname as part of the
USER command, even on the default site, and be able to decide when to turn
of the special IP address.

Regards,

Jan Mikkelsen
[email-masked]