> On Wed, Aug 08, 2007 at 04:00:26PM -0400, Sanford Walke IV wrote:
>> According to the customer, RFC 4217 says that the client (LFTP) should
>> wait for the 150 response after a STOR request, before using the data
>> channel. LFTP is not waiting.
>
> I have read the RFC 4217, it does not say that. It contains this:
>
> The server SHOULD only check the status of the data protection level
> (for options 3 and 4 above) on the actual command that will initiate
> the data transfer (and not on the PORT or PASV). The following
> commands, defined in [RFC 959], cause data connections to be opened
> and thus may be rejected before any 1xx message due to an incorrect
> PROT setting ...
>
> 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?
I've also read 4217 (now, that's what took me so long to reply), and in
Section 12, especially 12.6 and 12.7, it shows the client waiting for the
150 reply before beginning the data transmission. Admittedly, the header
to section 12 includes this:
"Of course, the FTP protocol itself is not well described with respect
to the timing of commands and responses in [RFC-959], so this is partly
based on empirical observation of existing widespread client and server
implementations."
That also implies that the "normal" or "accepted" way of handling a transfer
is to wait for the 150 reply before using the data connection. This is
born out by my experiences trying to STOR a file on an ftps connection
using lftp. It doesn't work properly. If it would wait for the 150, it
would work fine.
959 clearly describes the 150 reply as "File status okay; about to open
data connection.", which implies that the data connection doesn't
necessarily even exist until the 150 reply has been received by the
client. 150 is also an Preliminary reply, indicated by the 1 in the
first digit.
>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,".
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.
--
Sandy
Freedom is the opportunity to take responsibility for your actions.
I don't speak for anyone but myself, and sometimes not even that.
