DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18039>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18039 FtpProxy support [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Enhancement Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2003-03-16 20:33 ------- Changed severity to enhancement since this is not a bug. Although the contribution is appreciated, it isn't appropriate for a few reasons. In Commons Net, class behavior must be programmatic (through the API) and not dependent on system properties whenever possible. Individual applications may decide to have their own properties for configuration purposes, but the approach of Commons Net to date has been not to force the use of specific properties upon the end user (e.g., setProxy() is okay, but System.getProperty("ftpProxySet") is not). There must also be a way to remove the proxy (i.e., setProxy() needs to document that setting the proxy to null removes it, but it's better to have a disableProxy() or removeProxy() or some such). The preceding comments aside, there is no need for this patch. First, there is no RFC for FTP proxy servers, so this implementation is not guaranteed to work with all FTP proxies. For example, some proxies require separate authentication for using the proxy. Some do this by separating the proxy authentication from the FTP server authentication with a colon. We can't special case every single proxy's conventions. Second, FTP proxies are already usuable by establishing an FTP connection to the proxy with FTPClient. Applications that want to configure proxies should do so themselves, building on top of FTPClient. It is the responsibility of FTPClient to establish connections to FTP servers and negotiate the client side of the FTP protocol. It is not its responsibility to keep track of an application's proxy settings. If the use of FTP proxies with FTPClient is so common that some convenience methods are required, then a FTPProxyClient convenience class that subclasses FTPClient should be created instead of putting the convenience code in FTPClient itself. As it is, I see no point to this patch since one only has to call login() with a "[EMAIL PROTECTED]" name to use the proxy targeted by this patch with FTPClient. Further discussion should occur on commons-dev to debate the merits of proxy support (which is already supported ...) and what the use cases would be for a convenience class if deemed desirable. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
