[1] "ftp://xxxxx:xxxxxx at www.jway.lu/jpublisher/jway.xxe_addon" is handled by using Java's built-in java.net.URLConnection. Therefore this is probably a bug in Sun's FTP client code.
[2] May be the problem comes from this known Java bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4839995 Sun claims that this bug is fixed in Java 1.5. [3] I didn't manage to reproduce the problem with Java 1.4.1, 1.4.2, 1.5, 1.6, using SuSE 9.3 FTP server (vsftpd - Very Secure FTP Daemon, started using xinetd). I have used this URL ftp://hussein:XXXX at lupo.pixware.fr/xmleditor_site/site/_download/list.xxe_addon to do all my tests. Note that we don't use a proxy here at Pixware. Guy Bobenrieth wrote: > > We have some difficulties with using an ftp access to deploy our > XMLMind addon. > The ftp server is running under Ubuntu and is driven by pure-ftpd. > The ftp account is protected by a password. > > If I try to download our xxe_addon file, by using an url like > ftp://xxxxx:xxxxxx at www.jway.lu/jpublisher/jway.xxe_addon , I always get > an error message in the "Errors found while searching for add-ons" window : > Reading list of add-ons > "ftp://xxxxx:xxxxxx at www.jway.lu/jpublisher/jway.xxe_addon"... > Connection reset > > When a try to access to this url with my web browser, it works as expected. > > What can you suggest to find a solution to this problem. > > Some more informations about our ftp/addon issue : > > After doing some more tests and setting the pure-ftp server in debug mode, I > can see that : > > pure-ftpd: (?@ ip-83-99-57-21.dyn.luxdsl.pt.lu) [INFO] New connection from > ip-83-99-57-21.dyn.luxdsl.pt.lu > pure-ftpd: ([email protected] ) [DEBUG] Command [user] > [xxxxxx] > pure-ftpd: ([email protected]) [DEBUG] Command [pass] [<*>] > pure-ftpd: (?@ ip-83-99-57-21.dyn.luxdsl.pt.lu) [INFO] opoce is now logged in > pure-ftpd: (opoce at ip-83-99-57-21.dyn.luxdsl.pt.lu) [DEBUG] Command [type] > [I] > pure-ftpd: ( opoce at ip-83-99-57-21.dyn.luxdsl.pt.lu) [DEBUG] Command [cwd] > [jpublisher] > pure-ftpd: ( opoce at ip-83-99-57-21.dyn.luxdsl.pt.lu) [DEBUG] Command [epsv] > [ALL] > pure-ftpd: (opoce at ip-83-99-57-21.dyn.luxdsl.pt.lu ) [DEBUG] Command [epsv] > [] > pure-ftpd: (opoce at ip-83-99-57-21.dyn.luxdsl.pt.lu) [DEBUG] Command [eprt] > [|1|83.99.57.21|2580|] > pure-ftpd: ( opoce at ip-83-99-57-21.dyn.luxdsl.pt.lu) [INFO] Logout. > > An if a look Inside the RFC 2428, I can notice this : > > Finally, the EPSV command can be used with the argument "ALL" to inform > Network Address Translators that the EPRT command (as well as other data > commands) will no longer be used. An example of this command follows: > > EPSV<space>ALL > > Upon receipt of an EPSV ALL command, the server MUST reject all data > connection setup commands other than EPSV ( i.e., EPRT, PORT, PASV, et al.). > > Why then is the ftp library sending EPSV and EPRT to the server after th > EPSV ALL ? Could this explain our problem ? > > Waiting for your comments,
