Re: Native FTP proxying

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Wed, 05 Sep 2012 01:14:30 +0200

tis 2012-09-04 klockan 16:29 -0600 skrev Alex Rousskov:

> Why would "the second" approach be required by some? In other words,
> what kind of FTP functionality the first approach cannot support? I do
> not favor the second approach, but I would like to know what we are
> losing by using the first approach (other than some performance).

FTP is a rather messy protocol with many commands including site
specific commands which can not be easily mapped to HTTP semantics

And server state is also quite complex compared to HTTP.

If you do

cd /some/path/symlink
cd ..

then you end up in .. relative to the symlink, not /some/path/, which is
a bit of a headache for mapping longer sessions.

On servers using drive names/letters state gets even messier as you then
usually have one active path per drive. I.e. windows/dos and various old
mainframe OS:es.

But we do not need to cater for them all unless you plan on intercepting
port 21. And even then most of the odd ones can be ignored if there is
an acl to bypass interception on selected sites or users.

Regards
Henrik
Received on Tue Sep 04 2012 - 23:14:35 MDT

This archive was generated by hypermail 2.2.0 : Wed Sep 05 2012 - 12:00:09 MDT