RFC 1738 specifies that the '/' character separating the hostname from the url-path in a FTP url is a separator and should not be treated as a part of the url-path. Thus, ftp://foobar/baz/blah should retrieve the file 'baz/blah', but instead it tries to retrieve the file '/baz/blah'. How-To-Repeat: > fetch -vv ftp://yyy:zzz@xxx/foo/bar/baz scheme: [ftp] user: [yyy] password: [zzz] host: [xxx] port: [0] document: [/foo/bar/baz] ---> xxx:21 looking up xxx connecting to xxx:21 <<< 220 xxx FTP server (Version 6.00LS) ready.
Responsible Changed From-To: freebsd-bugs->des des@ asked me to file a bug report and assign it to him.
This patch fixes the issue with leading "/" in FTP URL paths. I originally wanted to make the change for this in the libfetch call to parse URLs, but it turns out that HTTP needs the / included. At least, Apache seemed to not like requests which did not have a leading slash. So, this basically checks for a leading slash and removes it (note that it will not remove multiple slashes--only the first). The next modification removes the code which assumed that all paths were relative to "/" in the _ftp_cwd function. If the attachment isn't in the right format, or you don't think my solution is ideal, let me know and I'll look into fixing it. Thanks, Kyle Larose Firmware Engineering Co-op www.sandvine.com
Similarly, ftp://foobar//baz/blah will also "CWD /baz" and "RETR blah". This is in violation of RFC 1738, which expects that to "CWD ", "CWD baz", 'RETR blah". Since all FTP servers that conform to RFC 959 will return a 5xx error code on a null parameter CWD, this is a reasonable thing to do instead. As a side effect, this fix also restores some previous minor functionality about handling extraneous slashes in the document portion of the url that was affected by the commit made to close bin/83278. Consider a ftp server with files: /file /foobar/file where CWD=/foobar upon connection. Since this change is not reverse compatible when connecting to ftp servers that do not start CWD in the root directory upon connection, the command "fetch ftp://<ftpserver>/file" would have fetched the file "/file", will now fetch the file "/foobar/file". To retrieve the file "/file" the user would have to issue the command "fetch ftp://<ftpserver>/%2Ffile" or "fetch ftp://<ftpserver>//file".
Testing shows this patch introduces a bug when libfetch is used to retrieve multiple files by FTP in the same connection. i.e. f = fetchGetURL(url1, ""); fclose(f); f = fetchGetURL(url2, ""); fclose(f);
Heh, weird how the message got clobbered. Sorry about that. Here is what I intended to send: ---------------------- Here is a change for libfetch to make it CWD properly if the ftp session does not start in "/". Libfetch will now prepend the starting directory to any CWD, unless the url specifies an absolute path such as ftp://host//absolute.txt I have created two diffs. One against Matt's changes that strip the leading slash that is taken from the host portion. Another is against HEAD, with the diff stripping the leading slash itself. The changes are in ftp_cwd(...) and in ftp_connect(...) functions.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped