Bugs item #1739100, was opened at 2007-06-18 16:25
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1739100&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ftp
Group: bad behaviour
>Status: Closed
Resolution: Fixed
Priority: 6
Private: No
Submitted By: Robson Braga Araujo (braga)
Assigned to: Daniel Stenberg (bagder)
Summary: Double slashes and root dir

Initial Comment:
Know bug number 6 states:
libcurl ignores empty path parts in FTP URLs, whereas RFC1738 states that such parts should be sent to the server as 'CWD ' (without an argument). The only exception to this rule, is that we knowingly break this if the empty part is first in the path, as then we use the double slashes to indicate that the user wants to reach the root dir (this exception SHALL remain even when this bug is fixed).

I think this means libcurl will ignore double slashes unless it's the first in the path, which will bring us to the root dir. But that's not what is happening. libcurl is always ignoring the double slashes leaving us with no way to list the root directory. (Except .. hacks)

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2007-06-19 23:00

Message:
Logged In: YES
user_id=1110
Originator: NO

Phew. Thanks for your report and patience with me. Closing this now.

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-19 22:49

Message:
Logged In: YES
user_id=307089
Originator: YES

I verified that it works for me. Thanks, Daniel.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-19 14:33

Message:
Logged In: YES
user_id=1110
Originator: NO

I added test case 353 now that tests this and I committed a fix that makes
the test run fine in my end!

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-19 14:17

Message:
Logged In: YES
user_id=1110
Originator: NO

ugh, of course. me stupid...

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-19 14:15

Message:
Logged In: YES
user_id=307089
Originator: YES

No, Daniel. libcurl can't issue a CWD / because it breaks the case where
the server puts you in a /home/user directory by default.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-19 14:11

Message:
Logged In: YES
user_id=1110
Originator: NO

Ah, ok, but that's expected since libcurl has no such path optimizing
logic. We could make one, but currently it will do this extra step.

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-19 14:05

Message:
Logged In: YES
user_id=307089
Originator: YES

singlecwd:
Try
curl ftp://ftp.sunet.se/ --ftp-method singlecwd -v

It will do a CWD / when it shouldn't. That's the issue.

nocwd:
I agree.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-19 13:55

Message:
Logged In: YES
user_id=1110
Originator: NO

singlecwd:

Just now I tried this with current CVS:

curl ftp://ftp.sunet.se// --ftp-method singlecwd -v

and

curl ftp://ftp.sunet.se/pub/ --ftp-method singlecwd -v

The first did a CWD / and a LIST, while the second did a "CWD pub" and a
LIST. I can't see a problem?

nocwd:

for directories we should probably make the directory name get used in the
LIST command instead, so that no CWD is used and LIST specifies the full
path. But I honestly don't plan on fixing this before the upcoming release,
while I want the problem you filed originally (with at least the default
ftp method setting) to work fine.

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-19 13:46

Message:
Logged In: YES
user_id=307089
Originator: YES

Ok. Let's break this into two issues:

singlecwd:
*Always* does a CWD /. This breaks the case where the server wants to put
you in a /home/user dir by default.

nocwd:
Current - doesn't work for directories, nocwd for files.
Proposed - one cwd for directories, nocwd for files.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-19 11:09

Message:
Logged In: YES
user_id=1110
Originator: NO

The nocwd.patch makes it do a directory listing, sure but it breaks the
promise of "no cwd". As test case 351 easily proves... Therefore I don't
consider it to be the proper fix. BTW, this nocwd bug is now added to the
KNOWN_BUGS document and I consider it separate from the problems we attempt
to fix in this bug report. It simply is broken.

I don't see any problem with singlecwd, neither with listing to the root
dir (test case 352) or listing a custom dir relative from the logged in dir
(test case 297).

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-19 00:08

Message:
Logged In: YES
user_id=307089
Originator: YES

Here is a patch for the nocwd problem. I haven't looked into the singlecwd
issue.
File Added: nocwd.patch

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-19 00:01

Message:
Logged In: YES
user_id=307089
Originator: YES

Also, if you use CURLFTPMETHOD_NOCWD, libcurl always does a SIZE and a
RETR, even if the url points to a directory.

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-18 23:58

Message:
Logged In: YES
user_id=307089
Originator: YES

Thanks for fixing.

> Funnily enough, the bug does not appear when using
> --ftp-method singlecwd

This is a bug too. If you use --ftp-method singlecwd, libcurl always sets
the path to /, despite an extra slash or not, instead of leaving you in the
default dir.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-18 23:06

Message:
Logged In: YES
user_id=1110
Originator: NO

I've committed fix for this now, and two test cases.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-18 19:46

Message:
Logged In: YES
user_id=1110
Originator: NO

I get it now. Funnily enough, the bug does not appear when using
--ftp-method singlecwd

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-18 19:38

Message:
Logged In: YES
user_id=307089
Originator: YES

ftp://ftp.sunet.se// gets the root dir because ftp.sunet.se doesn't
redirect you to a default dir. You can try it with curl -v and see that
there is no CWD / command being issued. I can reproduce it locally with a
FTP server that I configured:

$ curl -v ftp://robson@localhost//
* About to connect() to localhost port 21 (#0)
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 21 (#0)
< 220 ProFTPD 1.3.1rc2 Server (ProFTPD Default Installation) [127.0.0.1]
> USER robson
< 331 Anonymous login ok, send your complete email address as your
password
> PASS
< 230 Anonymous access granted, restrictions apply
> PWD
< 257 "/ssh" is the current directory
* Entry path is '/ssh'
> EPSV
* Connect data stream passively
< 229 Entering Extended Passive Mode (|||46110|)
* Trying 127.0.0.1... connected
* Connecting to 127.0.0.1 (127.0.0.1) port 46110
> TYPE A
< 200 Type set to A
> LIST
< 150 Opening ASCII mode data connection for file list
* Maxdownload = -1
* Remembering we are in dir /
< 226 Transfer complete
* Connection #0 to host localhost left intact
* Curl_disconnect
> QUIT
< 221 Goodbye.
* Closing connection #0

It is listing /ssh directory instead of the / directory.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-18 19:25

Message:
Logged In: YES
user_id=1110
Originator: NO

Sorry, but can you tell me what the problem is with this.
ftp://ftp.sunet.se// gets the root dir for you.

> Using ftp://ftp.sunet.se/%2F works well.

Actually, that does NOT work well I would say as that will make curl issue
"RETR /" which is plain wrong.

But ok, please confirm the following: I guess the problem here is you want
to list the root dir of an FTP server that doesn't let you in in the root
dir as default and you say this doesn't work? If it is, do you know of a
public server that you can repeat the problem with with a complete command
line?

(I guess you've said this all along but I haven't understood it)

----------------------------------------------------------------------

Comment By: Robson Braga Araujo (braga)
Date: 2007-06-18 17:36

Message:
Logged In: YES
user_id=307089
Originator: YES

This indeed works. But if you try just ftp://ftp.sunet.se// you won't be
changed to the root dir. ftp.sunet.se doesn't have a default home dir, but
you can see that there is no CWD / command given. Using
ftp://ftp.sunet.se/%2F works well.

I tried with curl-7.16.2.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2007-06-18 16:49

Message:
Logged In: YES
user_id=1110
Originator: NO

I can't repeat (or possibly understand) your problem:

I take it you use 7.16.2 or a recent CVS?

I tried with both doing this:

$ curl ftp://ftp.sunet.se//lib/ -v

And both versions jump to the directory "/lib" that is based on the root
dir of the server, not the home dir where it logs in.

I also tried the more official way of doing it, by specifying %2f instead
of the double slash, it it too worked with both these versions:

$ curl ftp://ftp.sunet.se/%2flib/ -v

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1739100&group_id=976
Received on 2007-06-19