Re: Native FTP proxying

On 09/04/2012 03:04 PM, Henrik Nordström wrote:
> tis 2012-09-04 klockan 12:22 -0600 skrev Alex Rousskov:
>
>>> A FTP client-side might be accepted, allowing Squid to act as an
>>> ftp->ftp gateway using HTTP semantics internally, even accepting
>>> ftp->http gatewaying if you want. But not sure it makes sense to add
>>> native FTP proxy support.
>>
>> Can you clarify the difference between "ftp->ftp gateway" and "native
>> FTP proxy support"? Please assume that we are "using HTTP semantics
>> internally" in both cases, which I interpret as not altering the
>> forward.cc and Store code much -- the new FTP code will convert FTP
>> commands into HTTP messages for internal processing and the code outside
>> FTP client and server modules will remain pretty much the same.
>
> An ftp->ftp gateway using HTTP semantics internally is a FTP server
> component (client_side..) that accepts FTP commands from FTP clients and
> maps them to HTTP semantics which is then proxied by Squid.
>
> Native FTP proxy support means acting as an FTP proxy relaying FTP
> commands between client and requested server without going via an
> internal HTTP sematics mapping.
>
>
> The first is very feasible and maps nicely to Squid.
>
> The second is very hard to fit within Squid in a meaningful manner other
> than to provide basic server level access control, but is required by
> some..

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).

Thank you,

Alex.
Received on Tue Sep 04 2012 - 22:29:25 MDT