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
