On Thursday 04 November 2010 12:02:38 Daniel Stenberg wrote:
> 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

I believe that is exactly the problem we are dealing with.

> 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.

It sounds like a good idea. But how would we recognize the case we need to
wait for some additional response?

I am considering the following scenarios:

1) > ABOR
   < 225 ABOR command successful.

2) > ABOR
   < 226 Since you see this ABOR must've succeeded

3) > ABOR
   < 226 File send OK.
   < 225 No transfer to ABOR.

4) > ABOR
   < 426 Failure writing network stream.
   < 225 No transfer to ABOR.

While the first two case imply a one-line response, the cases 3) and 4) lead
to a two-lines response. I guess we should rely only on the status codes,
not on the response text, right?

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-11-04