Menu

#661 Double slashes and root dir

closed-fixed
ftp (93)
6
2013-06-21
2007-06-18
No

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)

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2007-06-18

    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

     
  • Robson Braga Araujo

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-18
    • priority: 5 --> 6
     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-18

    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)

     
  • Robson Braga Araujo

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-18

    Logged In: YES
    user_id=1110
    Originator: NO

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

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-18

    Logged In: YES
    user_id=1110
    Originator: NO

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

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-18
    • status: open --> open-fixed
     
  • Robson Braga Araujo

    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.

     
  • Robson Braga Araujo

    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.

     
  • Robson Braga Araujo

    Patch for making CURLFTPMETHOD_NOCWD work with directories

     
  • Robson Braga Araujo

    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

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-19

    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).

     
  • Robson Braga Araujo

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-19

    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.

     
  • Robson Braga Araujo

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-19

    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.

     
  • Robson Braga Araujo

    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.

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-19

    Logged In: YES
    user_id=1110
    Originator: NO

    ugh, of course. me stupid...

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-19

    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!

     
  • Robson Braga Araujo

    Logged In: YES
    user_id=307089
    Originator: YES

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

     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-19
    • status: open-fixed --> closed-fixed
     
  • Daniel Stenberg

    Daniel Stenberg - 2007-06-19

    Logged In: YES
    user_id=1110
    Originator: NO

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