On Thu, 4 Nov 2010, Kamil Dudka wrote:

>> But, the server's response seems to indicate that the transfer was not
>> succesful in the first place: "426 Failure writing network stream" with the
>> following "225 No transfer to ABOR.". So why was ABOR sent? I think perhaps
>> the condition for sending ABOR should also check if 'premature' is TRUE so
>> that it only ABORs when closing before the expected end of transfer.
>
> We close the data channel in the middle of the data transfer. That is what
> causes the failure I think.

Right. But what exactly is the error that the shown trace causes? I mean, what
is the effect of the problem?

I wonder if the case we look at might actually work like this:

[client] decides it has received enough data and wants to stop receiving
[client] sends "ABOR"
[client] closes data connection
[server] detects closed data connection, tears it down
[server] sends "426 Failure writing network stream." response
[server] reads command connection, finds "ABOR" but there's no transfer going
          on so it sends a "225 No transfer to ABOR." response
[client] reads only a single response (in ftp_done()) and is fine with that,
          leaving a response "unread" which may cause funny side-effects

As in some servers will properly detect the closed transfer and some will not.

It could be noted that in the good old FTP RFC they talk about using the TCP
URG bit with ABOR just to "push it ahead" in the incoming queue in servers.
Something libcurl doesn't do. (URG is generally considered a totally broken
piece of TCP technology.) I don't know if that would make a difference in a
case like this.

> Checking the 'premature' flag does not solve the problem. At least it did
> not in the case of Pure-ftpd. The flag was not set anyway.

Ah ok, I guess we mean premature from curl's perspective and it isn't
premature then when it wants to stop on its own decision.

> I wonder if a solution would be to send ABOR, wait for a response and even
> then close the data connection?

Yes, I suspect we need to wait for the response to ABOR. Alternatively, we
make sure to not re-use the control connection after that point, but that
should only be done if we really don't know if we should read the response or
not.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html