Subject: Ftp-WG: HOST command and client upgrades

From: "Jan Mikkelsen" <[email-masked]>
Date: Mon, 25 Oct 1999 18:21:21 -0400

Robert Elz writes:

>  | My original suggestion was to force servers to fail any "new" command,
>  | unless the client sent HOST first,
>
>That's certainly an option for servers that are running virtual hosts.

My point is that if all servers, including those not depending on virtual
hosts, do it, then clients will be forced to upgrade faster.

>  | I suggested using FEAT to determine whether the HOST
>  | command should be required of a client.  It was quite correctly pointed
out
>  | that FEAT was specified in an earlier RFC, and so using it as an
indicator
>  | might not be such a great idea.
>
>Who said that?    For a client that has any idea at all about any of this
>(virtual host stuff I mean) then if the server says HOST in its FEAT
output,
>the client should certainly be sending a HOST command.   If the server
>doesn't say HOST in its FEAT output, then the client can still send a HOST
>command, but it ought be expecting a 500 type reply from the server
(unknown
>command).

Gregory Lundberg responded to my message.  The point is this:

- Until servers implement HOST, there is no incentive for clients to
implement HOST, regardsless of whether a server indicates its support for
host in a FEAT response.

- Until enough clients implement HOST servers will not depend on virtual
hosting.

- The break this loop, server behaviour could be more like that of an HTTP
server.  Specifically, if a server detects a client using a "new" feature
which is tied to HOST support, it should deny the "new" feature to clients
who have not generated a HOST command as part of their login sequence,
regardless of whether virtual hosting is used or not.

- This mandates using HOST for all clients that implement the "new" feature,
against servers which have HOST in their FEAT responses.

- I suggested using "FEAT" as the "new" feature to trigger this server
behaviour.  Something else may be more appropriate.

>  | But I must admit I do see it as a convenient way to force client
>  | implementors to support virtual hosts.
>
>I doubt that which doc it appears in will make much difference there.

No, but the wording of the document might help.  "If a client implements
MLST it must also implement HOST." would be pretty direct.  Or if server
MLST were specified as above, it would make a bigger difference.

>  | An alternative way of implementing virtual hosts might be not to have a
>  | separate command at all, but rather to overload the user command.
>
>That was suggested to me in private mail as well (wondering why the text
>in the draft is so demeaning of other virtual host schemes...).   That
>suggestion was to use user@host as the USER command data.

The problem I see with "user@host" rather than "host<delimeter>user" is that
the syntax of "user" is not clearly defined, and could, conceivably, contain
an '@' or whatever delimiter is chosen.  A DNS name has a precisely defined
syntax, and so detecting the delimiter isn't a big issue, and the delimiter
could subsequently appear in the username without there being a problem.

Incidentally, I have implemented virtual hosting this way, and it is being
used successfully with old clients.

>The difference between any scheme like that and the HOST command, is that
>the user cannot get any "you have connected to xxx" type messages that
>reference the virtual host name before they have logged in using the
>overloaded user command.   The HOST command is intended to be part of the
>initial connect sequence, allowing the welcome message to appear after it
>has been given instead of before.

Are these useful?  I guess they are to an extent.  In practice, however, how
much would it hurt to move host specific stuff after login?  Sites which do
not use virtual hosting can continue as they are now, sites which decide to
use virtual hosting get a new feature which imposes this restriction.

>The HOST method kind of permits virtual hosts to be implemented using
>a wrapper process, but I am not sure that there will ever actually be
>an implementation done that way.   Perhaps.

A wrapper process could still be constructed, it would just be a little more
work.  I don't think that an implementation issue like that should drive the
decision about how to design the protocol.

Jan Mikkelsen