commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18039] - FtpProxy support
Date Sun, 16 Mar 2003 20:33:30 GMT
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

dfs@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|Normal                      |Enhancement
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX



------- Additional Comments From dfs@apache.org  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 "user@host" 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message