On Thursday 04 November 2010 17:35:37 Number Cruncher wrote: > I'm the reporter for > https://bugzilla.redhat.com/show_bug.cgi?id=649347 and just have a > couple of additional remarks.
Thank you for gathering the info. > Firstly, how come you're sending ABOR anyway? Why doesn't the client > want to receive the whole file and instead tear down the transfer mid-flow? Because anaconda/yum developers are busy guys and they refuse to wait till the download is finished. > Secondly, I'd agree you absolutely have to wait for the ABOR response. > RFC959 outlines 2 cases for the server to handle when receiving this > command; either the server responds with 226 (abor successful) or a 426 > then 226. In the trace you mentioned, the server is in the middle of a Right, that is what RF959 says. > transfer process when it notices the socket reset, long before it sees > the ABOR. I think there might be a bug with VSFTPD in that it eventually > returns a 225 (not 226) "Data connection open; no transfer in progress" > even though it uses FTP_ABOR_NOCONN in the source code. > > You don't know at the time of sending ABOR and closing the connection > whether the server will process the closure before processing the ABOR. > So wait for a response; if it's 426 then also wait for a final response > to the original ABOR. It does not solve the following case: 3) > ABOR < 226 File send OK. < 225 No transfer to ABOR. I would be reluctant to continuously adjust our ABOR handling rules, so that they cope with more and more buggy FTP server implementations. We need to figure out something more generic I guess. > I can't believe we're still wrestling with fiddly connection race > conditions in a 30-year old network protocol! Is there actually any other FTP client successfully providing such a feature? I would be happy to look at its code... Kamil ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
