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
