Bug 83277

Summary: libfetch includes the leading / in FTP URL paths
Product: Base System Reporter: John Baldwin <jhb>
Component: binAssignee: Dag-Erling Smørgrav <des>
Status: In Progress ---    
Severity: Affects Only Me CC: des
Priority: Normal    
Version: 4.8-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
ftp.patch
none
libfetch-patch.txt
none
noslash.diff
none
HEAD.diff none

Description John Baldwin freebsd_committer freebsd_triage 2005-07-11 19:00:29 UTC
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.
Comment 1 John Baldwin freebsd_committer freebsd_triage 2005-07-11 20:04:43 UTC
Responsible Changed
From-To: freebsd-bugs->des

des@ asked me to file a bug report and assign it to him.
Comment 2 Kyle Larose 2007-09-28 15:32:36 UTC
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
Comment 3 Matt Koivisto 2008-09-11 15:54:17 UTC
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".
Comment 4 Ed Maste freebsd_committer freebsd_triage 2009-06-04 02:25:51 UTC
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);
Comment 5 Kirill Stepanchuk 2009-06-08 17:23:29 UTC
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.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:07 UTC
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