I'm the reporter for
https://bugzilla.redhat.com/show_bug.cgi?id=649347 and just have a
couple of additional remarks.
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?
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
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.
I can't believe we're still wrestling with fiddly connection race
conditions in a 30-year old network protocol!
Simon H.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
