Re: Native FTP proxying

fre 2012-08-17 klockan 18:03 -0600 skrev Alex Rousskov:

> What do you think about adding native or pure FTP proxying support
> to Squid? That is, is it a good idea for Squid to start accepting pure
> FTP requests (not wrapped in HTTP).

Not sure. It shares very little in common with HTTP proxying.

> Here are the pros and cons I could come up with:
>
> Pros:
>
> + There is definitely a persistent demand for native FTP support in
> Squid, especially in environments where Squid is used as a hub for
> content blocking and adaptation (various URL, ICAP, and eCAP filters).

Yes

> + FTP is expected to be around for the foreseeable future. Most diverse
> environments have at least one essential FTP client, possibly due to the
> ease of FTP client deployment on various platforms (not to mention
> legacy issues).

Yes

> + We already have server-side native FTP support so we do not have to
> start from scratch.

There is not much of our server-side native FTP support that can be
reused for actual FTP proxying. It's tailored for HTTP->FTP gatewaying.

> + Popular proprietary proxies (e.g., BlueCoat and McAfee WebGateway)
> support native FTP proxying.

Yes

> + Existing native FTP-only proxies (e.g., FROX and ftp-proxy) have very
> limited content blocking and adaptation functionality and, judging by
> their projects activity, one should not expect those and other modern
> deployment features to be supported in the foreseeable future.

Yes.

Not sure how much of of FTP that can be reasonably mapped to Squid
concepts. FTP is a quite different protocol compared to HTTP, with a lot
of state and legacy.

> Cons:
>
> - FTP is a dying protocol, responsible for just a few percent of traffic
> in most environments.

And most of that traffic is using FTP as if it was HTTP, i.e. browser
generated traffic.

> - There are existing native FTP-only proxies (e.g., FROX and ftp-proxy).

Yes, and several multi-protocol proxies.

> - This will further complicate client-side Squid code that is currently
> in a pretty bad shape.

It will complicate the whole forwarding path, not only client-side.
Proxyign of FTP has quite different requirements than HTTP.

> What do you think? Should a quality implementation of native FTP support
> be accepted by the Squid Project (with specific major design choices to
> be discussed before the development, as usual)?

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.

Regards
Henrik
Received on Sat Aug 18 2012 - 00:47:55 MDT