This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: ftplib and ProFTPD NLST 226 without 1xx response
Type: behavior Stage: test needed
Components: Library (Lib) Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: ajaksu2, giampaolo.rodola, loafman
Priority: normal Keywords: patch

Created on 2007-05-27 15:06 by loafman, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
ftplib.patch loafman, 2007-05-27 15:06 Fix for 226 without 1xx response.
trace loafman, 2009-04-06 13:12 ~/.ncftp/trace file to proftpd 1.3.1
Messages (8)
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) * (Python committer) 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) * (Python triager) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2022-04-11 14:56:24adminsetgithub: 45005
2010-04-18 14:12:43giampaolo.rodolasetstatus: open -> closed
resolution: out of date
2009-04-06 14:46:13loafmansetmessages: + msg85647
2009-04-06 14:09:40giampaolo.rodolasetmessages: + msg85646
2009-04-06 13:37:14loafmansetmessages: + msg85645
2009-04-06 13:29:10giampaolo.rodolasetmessages: + msg85643
2009-04-06 13:12:07loafmansetfiles: + trace

messages: + msg85642
2009-04-06 09:42:12ajaksu2setversions: + Python 3.1, Python 2.7, - Python 2.4
nosy: + ajaksu2

messages: + msg85625

type: behavior
stage: test needed
2007-05-27 15:06:18loafmancreate