[
https://issues.apache.org/jira/browse/FTPSERVER-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715317#action_12715317
]
Dennis Keller commented on FTPSERVER-287:
-----------------------------------------
Hi Niklas - I suppose my comment would be that regardless of the text of the
RFC, if you compare the Apache FTPServer response against that of other FTP
servers, you will see the difference (they return paths when the request
includes a path).
I included an example in my initial posting. I suppose you could interpret the
spec literally, however I urge to you test the cases I've provided using other
ftp servers. I believe the intent of the RFC is to behave similarly to a list
command on a UNIX machine. If you include the path in a list command, the
response will include the target path. The RFC says "... return a stream of
names of files...", which does not exclude the path, if the file was requested
with a path. For example:
If I execute "nlst file.txt", I expect a response of "file.txt"
If I execute "nlst directory/file.txt", I expect a response of
"directory/file.txt"
If I execute "nlst /directory/file.txt", I expect a response of
"/directory/file.txt"
If I execute "nlst ../parentdir/subdir/file.txt", I expect a response of
"../parentdir/subdir/file.txt"
This is how other FTP servers work and this is how unix works. The RFC is vague
and open to interpretation, therefore we need to look to other implementations
to find the consensus implementation. As it stands now, we are unable to use
the apache ftp server (before the patch) because of the significant
implementation difference.
Note that my patch may not be the best solution, however there is an
implementation issue now. So at the very least the test cases should be
included and the implementation constructed around them. I will provide more
examples if you require.
> NLST: Implementation only supports listing files in working directory [patch
> provided]
> --------------------------------------------------------------------------------------
>
> Key: FTPSERVER-287
> URL: https://issues.apache.org/jira/browse/FTPSERVER-287
> Project: FtpServer
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1
> Environment: Fedora 10-64bit and RH 5.2-64bit, Java 1.6.0_12-64
> Reporter: Dennis Keller
> Fix For: 1.0.2, 1.1
>
> Attachments: nlst.patch
>
>
> The NLST formatter, as implemented on trunk is insufficient to handle any
> request other than a file within in the current working directory. Some
> examples:
> ftp> passive
> Passive mode on.
> ftp> nlist /directory/file.txt
> 227 Entering Passive Mode (127,0,0,1,179,241)
> 150 File status okay; about to open data connection.
> file.txt
> 226 Closing data connection.
> Other FTP servers return the following:
> ftp> passive
> Passive mode on.
> ftp> nlist /directory/file.txt
> 227 Entering Passive Mode (127,0,0,1,179,241)
> 150 File status okay; about to open data connection.
> /directory/file.txt
> 226 Closing data connection.
> Upon investigating, I found that the formatter will not handle absolute file
> requests, parent directory request or non-absolute child directory requests.
> It does not error, it just doesn't give useful output.
> I've modified the code to handle the cases that I could come up with, but
> there may be other situations that need to be covered. I'm not an expert on
> the FTP specification (but what I could find was not impressive), so there
> many be additional cases that need to be covered.
> Please consider the attached patch, with accompanying test cases
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
