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.
