cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: FTP 3rd party transfers

From: Alexander Krasnostavsky <ALEXKRA_at_Amdocs.com>
Date: Sun, 16 Jan 2005 11:54:34 +0200

Hi,

1. All the new options are the same as it in regular URL but for source
server:
 
  SOURCE_HOST - source host name (the same as in URL)
  SOURCE_USERPWD - source user and password (the same as USERPWD)
  SOURCE_PATH - source file path (the same as in URL)
  SOURCE_PORT - source server's port number (the same as FTPPORT)
  PASV_HOST - New option: when doing 3rd party transfer, decide which
server that should get the PASV command (and the other gets the PORT).
     0 (default) - The target host issues PASV.
     1 - The source host issues PASV
 
  SOURCE_PREQUOTE - source pre-quote linked list of commands (the same
as PREQUOTE)
  SOURCE_POSTQUOTE - source post-quote linked list of commands (the same
as POSTQUOTE)

   The transfer will be done from source to target.

2. You are right about the case of both source and target is the same
server. Therefore I recommend add indicators for source and target to
distinguish between them.
   To make 3rd party transfer work, FTP server must support this mode,
i.e. in this mode user in FTP CLI can execute command using 'proxy'
world. I don't know how it implemented in the server side. I am using OS
standard FTP servers. RFC description of 3rd party mode I already post
here.
For example, 'man ftp' on HP says:
proxy ftp-command
           Execute an ftp command on a secondary control connection.
This
           command allows simultaneous connection to two remote FTP
servers
           for transferring files between the two servers. The first
proxy
           command should be an open, to establish the secondary control
           connection. Enter the command proxy ? to see other FTP
commands
           executable on the secondary connection. The following
commands
           behave differently when prefaced by proxy: open does not
define
           new macros during the auto-login process, close does not
erase
           existing macro definitions, get and mget transfer files from
the
           host on the primary control connection to the host on the
           secondary control connection, and put, mput, and append
transfer
           files from the host on the secondary control connection to
the
           host on the primary control connection. Third party file
           transfers depend upon support of the FTP protocol PASV
command by
           the server on the secondary control connection.

3. I didn't find any example in RFC documents of using 3rd party
transfer in URL. Therefore it depends on you to decide how URL will be
defined to have both servers in it. In any case, if there is no place in
URL for the second server, one of them should be defined using these
options. And there are no difference/benefits of choosing source or
target. Another way, I didn't think before, is to define SOURCE_URL
additionally to URL (once again, source or target is not important
because one of them must be defined separately).

I will glad to help you with any knowledge I have. Just ask me concrete
questions.

Alexander

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Saturday, January 15, 2005 23:47
To: curl-library_at_cool.haxx.se
Cc: Alexander Krasnostavsky
Subject: FTP 3rd party transfers

Hiya,

As I described the other day, we need to add 3rd party transfers to the
test
suite, as otherwise it'll be much harder to get it working properly with
my
brand new FTP code.

In my ongoing venture in attempting this, I just added a bunch of new
command line options to curl so that I can try 3rd party transfers from
the command line (patch available on request). What did I learn from
this? Several things:

1. The libcurl options for 3rd party transfers are totally undocumented,
which makes me believe that no one but Alexander has ever used this, as
it is not obvious how this is used (the ftp3rdparty.c example helps, but
it is not complete and does not explain the options).

2. I can't make 3rd party transfers work when I try them. (The debug
output is also not very good when both source and target is the same
server and thus same host name as you can't really tell the difference
between source and target server operations.)

3. I don't like the pletora of options that would be better as one
single source URL instead of separated into source host, source path,
source port etc. It is unintuitive since the target is specified as a
URL. Is there any benefits from using this approach that I don't see?

Since I can't make 3rd party transfers work, I can't make the test suite

support tests using it either.

Since I can't make the test suite test 3rd party transfers, I can't
convert
them over to the new state-machine FTP code easily.

If I can't convert the code, 3rd party won't work after my FTP rewrite
and
thus I don't see any reason to keep it.

Summary:

I'd like to support FTP 3rd party transfers, so I need assistance to get
it
done right. And with right I mean that I want to be able to use it, I
want the docs to describe how to use it and I want the test suite to
test at least the most common cases and options. Based on the current
code of course. The conversion to state-machine code will be made
separately.

I'm asking for help. I can't make this on my own.

If I don't get help within reasonable time, I'll just remove the 3rd
party
transfer support in my rewritten code, and then we'll re-introduce 3rd
party
transfer later on...

--
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html

The information contained in this message is proprietary of Amdocs,
protected from disclosure, and may be privileged.
The information is intended to be conveyed only to the designated recipient(s)
of the message. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, use, distribution or copying of
this communication is strictly prohibited and may be unlawful.
If you have received this communication in error, please notify us immediately
by replying to the message and deleting it from your computer.
Thank you.
Received on 2005-01-16