Subject: Re: [ACADEM-SW-SUPPORT #154] Re: Status of 2.4.2-academ[BET

From: Will Brown <[email-masked]>
Date: Fri, 17 Jan 1997 11:07:55 -0500 (EST)

Hostname based virtual FTP *IS IMPOSSIBLE* unless you want to try and
change the protocol, and all of the client software.  Simply put, the
HTTP protocol was changed to support virtual web hosting. The target
host *name* is now sent by many clients (browsers) to enable this
feature - it was so important that it happened.

To do the same with FTP, you would have to add a similar feature to
the FTP protocol and get enough of the existing client software
modified to make it worthwhile.

Since HTTP does (almost) replace FTP for anonymous applications, I'd
suggest that you are beating on a dead horse.

NOT to say that FTP does not have its technical advantages - it does -
but I personally don't think they are important enough to make this
happen.

--
Will Brown <[email-masked]>

---

From: Evan Champion <[email-masked]>
Date: Fri, 17 Jan 1997 16:00:55 -0500 (EST)

On Fri, 17 Jan 1997, Stuart Rosewall wrote:

> What I would like to see, and perhaps the original poster is in agreement
> here, is a way of using one IP address between several virtual FTP setups.
> As the patch is somehow able to determine the IP from the hostname
> information, could not some work be done to perform this type of function...

Unfortunately, you can't do that.

The way virtual services work is by checking the IP address a user 
connected to.  That is how a the server can tell if a user wanted 
ftp.foo.com or ftp.bar.net.  So for all virtual services you need to have 
multiple IP addresses.

The reason web servers can get around this is because HTTP/1.1 clients 
send as part of their query the name of the host they're trying to get 
to, so the server has all the information it needs to decide whether you 
wanted www.foo.com or www.bar.net.

Note that this method doesn't work for HTTP/1.0 clients, and there are an 
awful lot of them, so even for web servers this technique isn't 
necessarily usable now (by this time next year, however, you'd probably 
be safe to do it as most people who have updated their browsers to a 
version that does send the destination host in the query).

Of course, this functionality could be added to the FTP protocol, but a 
reality check says this is never going to happen.  You're never going to 
get all the vendor code updated, and really there isn't the demand for 
it.  It is a lot easier with HTTP was there are only a limited number of 
browsers, and the browsers are fast-changing so new technology can have a 
large penetration in basically no time.
 
IMHO, and I know I'm going to get a lot of flak for this, the solution is
to not offer virtual FTP service.  I offer it for my customers, but 99% of
them don't use it anyway.  I also offer FTP service for my non-virtual
customers and 99.9% of them don't use it for serving files (only for
putting up their web pages).  Eventually, Apache/Stronghold will have all
the Netscape document upload etc. stuff so FTP won't really be necessary. 

Evan
--
Evan Champion            * Director, Network Operations
mailto:[email-masked] * Directeur, Exploitation du reseau
http://www.synapse.net/  * Synapse Internet

---

From: [email-masked] (Koos van den Hout _U nix and we all_)
Date: Fri, 17 Jan 1997 22:21:22 +0100 (MET)

Quoting Bob Myers, who wrote :

> So to make this work for FTP, you'd not only have to change the protocol
> to support it, but you'd have to be sure anyone accessing your non-IP
> based virtual FTP site had an FTP client that supported the new FTP
> protocol.  I just don't think that's going to happen.

With ftp clients like :

asterix>ls -l /usr/ucb/ftp
-r-xr-xr-x   1 root     bin        96220 Sep  9  1991 /usr/ucb/ftp

asterix>uname -a
asterix asterix 3.2 2 i386

(Interactive Unix)

in daily use, that's not going to happen. Browsers appealed to the 'get
the latest version every time' crowd. Ftp clients using the protocol we're
talking about where here since about 1975.

					     Grtx KH

Bytheway: I'm back.. and as soon as there is some time for it I'll
work through the backlog in the faq.

Expect the faq to move to http://www.cetis.hvu.nl/~koos/wu-ftpd-faq.html
(with a redirect from the old address). We're reorganizing webservers.

-- 
  Koos van den Hout,     Internetter, Unix freak, ISFJ and BBS SysOp at large
  [email-masked] (Work)  <-- finger -l for PGPkey      Fax: +31-30-2586290
  [email-masked] (Home)                      Workphone: +31-30-2586287
  http://www.hvu.nl/~koos (WWW)    Looking for a license plate with "RFC 822"

---

From: Norbert Crettol <[email-masked]>
Date: Mon, 20 Jan 1997 08:14:49 +0100 (GMT+0100)

On Fri, 17 Jan 1997, Karl O. Pinc wrote:

> 
> Nothing I know of is stopping you from using another port.  Just as
> http://www.x.com/index.html can be different from
> http://www.x.com:8000/index.html so can ftp://ftp.x.com/pub be different
> from ftp://ftp.x.com:2100/pub.  Depending on your requirements, you may

I've used this method to test the new ftpd, and it works without 
problems. It is mentioned in the FAQ at 

http://www.hvu.nl/~koos/wu-ftpd-faq.html

5.2 :
--------------------------------------------------------------------------
2.Testing on a different port number then ftp 

You can test the wu-ftpd on a different port by adding two ports with
consecutive numbers in /etc/services, and then starting wu-ftpd on these
ports. Add to /etc/services something like : 

            ftptest         4021/tcp        #command port    
            ftptest-data    4020/tcp        #data port

Then start wu-ftpd from /etc/inetd.conf like : 

            ftptest stream tcp nowait root /usr/etc/in.ftpd in.ftpd

The key is the name 'ftptest' which associates the port assignment in the
/etc/services file to that in the inetd.conf file. Make certain the choice 
of ports in /etc/services (4021 and 4020 above) are from the local 
use list and don't
conflict with other port assignments (see RFC1700, ASSIGNED 
NUMBERS).
One important subtlety. The data port is not really derived from the data port
declaration in the /etc/services file. The FTP specification (RFC765) states
the data port is defined as one less than the command port. 
However, including the data port declaration in the /etc/services 
file prevents it from being accidentally assigned to something else. 

            From a mail by W. James Showalter ([email-masked])  
-------------------------------------------------------------------------
-----------------------------------------------------------------
Omedia sa              Av. de la Gare 38          CH1920 Martigny
-----------------------------------------------------------------
Norbert Crettol                                 Internet services
[email-masked]                                  connexions, conseil
++41 27 722 04 50     http://www.omedia.ch        creation de Web
-----------------------------------------------------------------