[ 
https://issues.apache.org/jira/browse/NET-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676336#comment-13676336
 ] 

Arno Unkrig commented on NET-508:
---------------------------------

Hello Sebb,

bq. AFAICT it's already possible to use NET code with an FTP proxy. One just 
has to connect (and perhaps login) to the proxy rather than the target host, 
and then tell the proxy how to connect to the target host.\\After that 
presumably one uses standard FTP commands which are routed via the proxy.

Yes, some of the connection methods that I described can be implemented this 
way. However I could not find any documentation how this is to be done, so it's 
up to the application programmer to research it (like I did).

bq.What about logout? How does that work?

As usual...
* Either the client closes the control connection, which causes the prox to 
close the control connection to the remote server,
* or the client sends a QUIT command, which causes the remote server to close 
the control connection, which causes the proxy to close the control connection 
to the client.

bq.I'm not entirely convinced that there is a need to create a special method 
to do the work.\\Expecially since there is no standard for this - the resulting 
method might become very complicated if it has to support lots of different 
server types. That is going to be additional work to maintain,

I'd say that *because* FTP proxy handling is so complicated, it *should* be 
handled by a method in a library, and not on the application side. And 
COMMONS-NET would be the ideal place.

bq.and the user base for such proxies is likely to be a very small percentage 
of NET users.

Well, like there is demand for HTTP proxy support, there is demand for FTP -- 
e.g. to upload data from within a corporate LAN to an FTP server on the 
internet. Isn't it annoying that users can access FTP servers through 
FILEZILLA, but Java programs can't?

bq.Whereas it would be relatively easy for the end user to create a specific 
login script for their particular proxy, perhaps from an example template which 
they could customise.

I envisage that, like for HTTP, users would simply say 'Proxy server=..., 
port=..., userid=..., password=...', and not have to fiddle around with login 
scripts and the FTP protocol.

Could I convince you to some extent? Are there any other opinions?
                
> Add support for FTP proxies
> ---------------------------
>
>                 Key: NET-508
>                 URL: https://issues.apache.org/jira/browse/NET-508
>             Project: Commons Net
>          Issue Type: Improvement
>          Components: FTP
>    Affects Versions: 3.2
>            Reporter: Arno Unkrig
>
> The COMMONS-NET FTP client supports 'FTP over HTTP', but not the other 
> popular FTP proxy schemes. The article
>  http://www.codeproject.com/Articles/9547/How-Proxy-Server-serves-FTP-clients
> describes some of them, but not very precisely an obviously a bit incorrect.
> I added proxy support for the ANT FTP task in
>  
> https://svn.code.sf.net/p/loggifier/code/trunk/ant_issue_54883/src/org/apache/tools/ant/taskdefs/optional/net2/FTP2.java
> (search for string "proxyServer"), but I believe that the feature should be 
> implemented in COMMONS-NET, not in the application, maybe like this:
> {code}
> connectToProxyAndLogin(server, port, userid, password, proxyServer, 
> proxyPort, proxyUserid, proxyPassword)
> {code}
> The proxy server that I (must) use is
> {noformat}
> 220 McAfee Web Gateway 7.2.0 build 13935
> {noformat}
> , and from experiments it supports the following authentication schemes:
> {noformat}
>  (1) USER pu PASS pp OPEN ftp.acme.com[:port] USER u                     PASS 
> p
>  (2) USER pu PASS pp                          USER [email protected][:port] 
> PASS p
>  (3) USER pu PASS pp SITE ftp.acme.com[:port] USER u                     PASS 
> p
> {noformat}
> I don't know which FTP proxy servers support which of these flavors, but (2) 
> appears to be the most natural and robust to me.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to