| msg52679 - (view) |
Author: Kenneth Loafman (loafman) |
Date: 2007-05-27 15:06 |
| When ProFTPD and others do an NLST on an empty directory, they return a '226 Transfer Complete' without a 1xx response following (passive mode). They also may reset the connection, producing a '104, Connection reset by peer'. This patch corrects the 226 without 1xx response. Due to bug reports on ProFTPD indicating that the connection reset may be their issue, this patch does not address that problem. |
|
|
| msg52680 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) *  |
Date: 2007-06-15 22:00 |
| According to RFC959 the returning output of LIST and NLST commands should be sent over the data connection. Avoiding to open data connection and directly responding with "226 Transfer complete" when no transfer has occurred just because directory is empty is a wrong behaviour. The problem, if it really exists (are you really sure? It seems very strange to me), is up to ProFTPd, not ftplib. In case it really exists it is not within the realm of problems that should be dealt with by base ftplib since that it's a non RFC-compliant behaviour occurring with a particular product (ProFTPd). Best regards billiejoex |
|
|
| msg85625 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-04-06 09:42 |
| Kenneth: can you confirm this is a valid issue? |
|
|
| msg85642 - (view) |
Author: Kenneth Loafman (loafman) |
Date: 2009-04-06 13:12 |
| Yes, there is no 1xx response. I've attached a log between ncftp client and ProFTPd 1.3.1-6ubuntu1 that clearly shows no 1xx after the 226. |
|
|
| msg85643 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2009-04-06 13:29 |
| I keep saying this is not a valid issue. The 1xx response is supposed to be sent by the server *before* the 226 response, and that's what your log shows: 07:55:03 Cmd: PASV 07:55:03 227: Entering Passive Mode (192,168,1,13,160,7). 07:55:03 Cmd: LIST 07:55:03 150: Opening ASCII mode data connection for file list 07:55:03 226: Transfer complete After the 226 response the server just shuts up waiting for the client to send the next command. |
|
|
| msg85645 - (view) |
Author: Kenneth Loafman (loafman) |
Date: 2009-04-06 13:37 |
| Clearly not valid if you are strictly RFC compliant, however, if you want to be functional in the real world then it needs to be addressed. ProFTPd is not the only server that handles things this way, so from a functionality and compatibility standpoint, it should be fixed. BTW, I've already voted for functionality over forced compliance by moving duplicity backup from ftplib to ncftp since ncftp talks to most servers without complaint. RFC compliance is nice, but FTP servers just are not compliant in the real world. |
|
|
| msg85646 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2009-04-06 14:09 |
| According to the log file you have attached Proftpd always sends 1xx before 226 which is the RFC-compliant and widely adopted behavior, *also* when it's listing the content of an empty directory. See: 07:55:19 Cmd: LIST 07:55:19 150: Opening ASCII mode data connection for file list 07:55:19 226: Transfer complete 07:55:19 Remote listing contents { 07:55:19 } There's really no reason for an FTP server to send 1xx after 226, no matter if the listed directory is empty or not. It just doesn't make sense. Plus, Proftpd clearly *not* behave as such, as it is shown by your log file. |
|
|
| msg85647 - (view) |
Author: Kenneth Loafman (loafman) |
Date: 2009-04-06 14:46 |
| It's been a couple of years since I reported this and its entirely possible that the updated ProFTPd I'm now testing against has been fixed, and that ftplib has evolved since then. Short of one of you testing the current ftplib against a current ProFTPd, I would have to say that the problem has now been resolved. |
|
|