Native FTP proxying

Hello,

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

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

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

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

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

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

Cons:

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

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

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

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

Thank you,

Alex.
Received on Sat Aug 18 2012 - 00:04:20 MDT