Subject: Virtual FTP with only one IP?

From: Jeremy Hansen <[email-masked]>
Date: Thu, 18 Dec 1997 08:52:22 -0500

I'd like to create a virtual ftp server on a CNAME'd host
due to my limited supply of IP's.  Is this possible.  I'd
like to do what's allowed in virtual httpd serving.

Thank you!
-jeremy

---

From: Bernhard Rosenkraenzer <[email-masked]>
Date: Thu, 18 Dec 1997 14:11:02 +0000 (GMT)

> like to do what's allowed in virtual httpd serving.

It isn't possible because the ftp protocol doesn't transmit hostnames, but
I like the idea... Maybe it's time to make an addition to the ftp RFCs.

LLaP
bero

---

From: Jeremy Hansen <[email-masked]>
Date: Thu, 18 Dec 1997 10:01:08 -0500

It would be nice.  Basically it's to the point with httpd
that you only need one IP to do everything you could possible
want (apache).  Some user would like virtual ftp's and since 
I'm limited in IP space (which is taken up by machines), I'm 
unable to this.

Thanks!
-jeremy

---

From: Kent Landfield <[email-masked]>
Date: Thu, 18 Dec 1997 09:34:05 -0600 (CST)

While it would be nice, it is not possible. Virtual FTP servers take
the address information directly from the connection itself.  In other
words, the ftp server determines which virtual server to use  based
on the IP address to where the connection is made.  httpd has the
benefit of being able to read the URL supplied after the connection
is made. It can check if the hostname in the URL requested matches 
one of the configured virtual hosts and then respond accordingly.
The FTP protocol has no capability at present to pass that type of
information on initial connection.

While this has been discussed as a valuable need at present there are
serious problems due to the installed base of ftp client software. Any
changes to the protocol will need to be backward compatible.  This
basically puts you right back in the same boat that if you want virtual
hosted domains/sites you will need to assign IP addresses. 

Maybe IPV6 will be our saviour... :) yeah right... ;)

# It would be nice.  Basically it's to the point with httpd
# that you only need one IP to do everything you could possible
# want (apache).  Some user would like virtual ftp's and since 
# I'm limited in IP space (which is taken up by machines), I'm 
# unable to this.
# 
# Thanks!
# -jeremy
# 
# > On Thu, 18 Dec 1997, Jeremy Hansen wrote:
# > 
# > > I'd like to create a virtual ftp server on a CNAME'd host
# > > due to my limited supply of IP's.  Is this possible.  I'd
# > > like to do what's allowed in virtual httpd serving.
# > 
# > It isn't possible because the ftp protocol doesn't transmit hostnames, but
# > I like the idea... Maybe it's time to make an addition to the ftp RFCs.
# > 
# > LLaP
# > bero
# 

-- 
Kent Landfield                        Phone: 1-817-545-2502             
Email: [email-masked]             http://www.landfield.com/
Email: [email-masked]                   http://www.nfr.net/
Please send comp.sources.misc related mail to [email-masked]
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/

---

From: Anders Thulin <[email-masked]>
Date: Fri, 19 Dec 1997 08:12:54 +0100 (MET)

> one of the configured virtual hosts and then respond accordingly.

  To be nitpickingly precise, the HTTP client uses the HTTP 'host'
command to tell the server that it expects to use the virtual server
associated with that domain name. This was one of the changes required
in the HTTP protocol to support virtual WWW-servers.

> information on initial connection.

  It could easily be added, just as WU-FTP supports a number of non RFC959
commands. One possibility would be to use:

	XHOST domain-name

once per session, and sufficiently early in the session. It requires
that FTP clients are changed to send an XHOST-command just before user
authentication, assuming passwords may be managed per virtual domain. This
modification is trivial for clients where the source code is available.

  There are no apparent drawbacks - old clients still work with 
XHOST-servers, and new clients can use the command status to decide
if XHOST is supported at the server end or not. If it isn't, the best
course of action is probably to ignore the error message -- that would
make the FTP session look exactly the same as an non-XHOSTed FTP session
with the same CNAMED host.

  Another possibility is to check if the hostname is a CNAME. If so,
use XHOST. If not, don't, as there can be no virtual domains there.
I don't see this is  major improvement, but it might help making error
messages at the client end more detailed.

  Using 'SITE HOST domain' instead of XHOST is another possibility,
and somewhat neater, as SITE is in RFC 959.

  The only problem seem to get the appropriate change made to the FTP
clients. If the extension can be demonstrated to work with UNIX-clients,
I rather suspect it wouldn't be too difficult to convince other FTP
client makers to make the change. 

Anders Thulin       [email-masked]        013-23 55 32
Telia Engineering AB, Teknikringen 6, S-583 30 Linkoping, Sweden

---

From: Kent Landfield <[email-masked]>
Date: Fri, 19 Dec 1997 10:00:31 -0600 (CST)

# Ken Landfield writes:
#   To be nitpickingly precise, the HTTP client uses the HTTP 'host'
# command to tell the server that it expects to use the virtual server
# associated with that domain name. This was one of the changes required
# in the HTTP protocol to support virtual WWW-servers.

I stand properly corrected. ;)

# > The FTP protocol has no capability at present to pass that type of
# > information on initial connection.
# 
#   It could easily be added, just as WU-FTP supports a number of non RFC959
# commands. One possibility would be to use:
# 
# 	XHOST domain-name
# 
# once per session, and sufficiently early in the session. It requires
# that FTP clients are changed to send an XHOST-command just before user
# authentication, assuming passwords may be managed per virtual domain. This
# modification is trivial for clients where the source code is available.

Again, you are correct. It could be added to the spec (hense my "at present")
and support could begin to show up. The problem is the installed base of ftp
software.

#   The only problem seem to get the appropriate change made to the FTP
# clients. If the extension can be demonstrated to work with UNIX-clients,
# I rather suspect it wouldn't be too difficult to convince other FTP
# client makers to make the change.