On Thu, Aug 16, 2007 at 02:48:50PM -0400, Sanford Walke IV wrote:
> > Nothing indicates that ftp client cannot start writing data to data
> > socket before 1xx reply (but after the connection is established, of
> > course).
>
> I respectfully disagree. Until the client receives the 150 reply, what
> indication is there that the data connection even exists?
The data connection is plain TCP connection or SSL connection, both of them
have a clear indication of being connected. Before it is connected lftp
does not (and cannot) write data to it.
> From the description of replies:
>
> 1yz Positive Preliminary reply
>
> The requested action is being initiated; expect another
> reply before proceeding with a new command. (The
> user-process sending another command before the
> completion reply would be in violation of protocol; but
> server-FTP processes should queue any commands that
> arrive while a preceding command is in progress.) This
> type of reply can be used to indicate that the command
> was accepted and the user-process may now pay attention
> to the data connections, for implementations where
^^^^^^^^^^^^^^^^^^^^^^^^^
> simultaneous monitoring is difficult. The server-FTP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> process may send at most, one 1yz reply per command.
>
> The most applicable part in that seems to be this: "This type of reply
> can be used to indicate that the command was accepted and the user-process
> may now pay attention to the data connections,".
lftp is capable of simultaneous monitoring of control and data connections,
so this paragraph does not apply.
> This is a show-stopper for my application of lftp, which is a shame, since
> it works so nicely otherwise for what I'm doing. I'll probably have to
> switch to cURL to get around this STOR problem.
I bet the problem is somewhere else and waiting for 150 is irrelevant.
--
Alexander..
