diff --git a/lib/connection.js b/lib/connection.js index 606de14..3c90fbd 100644 --- a/lib/connection.js +++ b/lib/connection.js @@ -580,11 +580,33 @@ FTP.prototype.get = function(path, zcomp, cb) { }; function ondone() { - if (done && lastreply) { - self._send('MODE S', function() { + if (done) { + if (zcomp) { + // Switch back to mode stream only when compression mode + self._send('MODE S', function() { + source._emit('end'); + source._emit('close'); + }, true); + } else { + // Some clients do not close the data connection until they receive the 226 response from the server. + // This behavior is permitted by RFC 959. (The intent, now obsolete, was for clients to retrieve multiple + // files through one data connection, with a self-delimiting encoding of each file. The server could use + // 226 to say that it was closing the connection, or 250 to say that it wasn't. The most obvious client + // implementation wouldn't close the connection until it received 226.) However, I recommend that clients + // close the data connection immediately after seeing the end of data. One server, wu-ftpd 2.6.0, waits + // until the client closes the connection before it sends its 226 response; this screws up file transfers + // to clients that do not close the data connection immediately. This also wastes a round-trip time for other + // clients. (As of 1999, various versions of wu-ftpd run about half of the Internet's FTP servers. Many + // servers made an emergency switch to version 2.6.0 in October 1999 when major security holes were + // discovered in previous versions.) + // + // Referred from https://cr.yp.to/ftp/retr.html + // + // End/Close emmediately, not waiting for 226 or 250 any more. + source.resume(); source._emit('end'); source._emit('close'); - }, true); + } } }