Daniel,

Thanks for your feedback. Please note that I'm using libcurl, not curl, and
that I'm providing ftp through a very simple end user UI like the following
one:

 server address: ftp.myserver.com
 server port: 21
 username: justinkahn
 password: tiptoe
 root folder: /justinkahn/somedir/someotherdir/

I have no control on the relative url entered by the user, and in fact, it
is given to them by their systems administrator.

>> Thanks for your feedback, you helped me dig a little better and correct my
>> analysis. Here is the scenario, a user named justinkahn tries to connect to
>> the server in order to emit a LST command. The relative url entered by the
>> user looks like the following:
>>
>> /justinkahn/somedir/someotherdir/
>
> But this isn't "relative", is it?

It's relative to the server, that's what I meant.

>> curl: PWD
>> server: 257 "/justinkahn" is current directory.
>> curl: CWD justinkahn
>> server: 550 justinkahn: The system cannot find the file specified.
>
> The server clearly reports to already be in the "/justinkahn" directory. Why
> would the user then attempt to change into a dir named like that?

It's not the user who is attempting to change dir, it's libcurl which does
that itself, because the requested url is /justinkahn/somedir/someotherdir/.
The CWD commands are issued automatically by libcurl in the ftp_perform
method through a loop.

> This looks like you're logging on with a user that enters in his own directory
> and thus you won't need to specify that on the command line. And if you _do_
> want it on the command line (in the URL) you shoud make sure that you use an
> absolute path so that curl will try that path from root and not from the
> current directory.

The user doesn't know where he is. He thinks he's at the ftproot, not in the
subdirectory named justinkahn.

The url I query IS an absolute url. It looks like the following:

ftp://justinkahn:tiptoe@ftp.myserver.com/justinkahn/somedir/someotherdir/

It doesn't work ! If I set it to

ftp://justinkahn:tiptoe@ftp.myserver.com/somedir/someotherdir/

It does.

So it looks like libcurl is NOT trying the path from root.

>> However it seems that Microsoft users are used to enter the prefixed url.
>
>> Both urls
>
> What both URLs?

"/justinkahn/somedir/someotherdir/" and "/somedir/someotherdir/"

>> work fine with Internet Explorer on Windows and MacOS X and with Transmit on
>> MacOS X
>
> What about Mozilla?

I've checked, and no, Mozilla reports a 550 error too.

>> so I tend to think that the prefixed url is somewhat legal
>
> ... if you say "common" instead of "legal" I think I'm leaning towards
> agreeing with you. I still don't understand why there's a need for us to
> support this though, the input URL clearly is wrong so why not just tell the
> user that?

>> or at least a de facto Microsoft standard, but it's not handled by curl.
>
> I believe curl follows RFC959 pretty closely, with only some minor descrepancy
> in the PWD part in the RFC1738 department mainly due to contradictions and
> server-related "problems".
>
> Is there a benefit to anyone to accept a path that clearly is bad?

I believe the path:

ftp://justinkahn:tiptoe@ftp.myserver.com/justinkahn/somedir/someotherdir/

Is correct, but that either there is a bug in the Microsoft ftp server, or a
bug in libcurl.

And since there is no way I can get Microsoft to fix their bug (if there is
one), and no way I can explain to users that the path they enter
successfully in IE is not correct, the only way for me to go is to find a
workaround in libcurl itself.

Please understand that the only goal here is to provide compatibility with
existing tools and habits, not only with RFC. It's difficult to explain to a
user that the path he enters is wrong when it works perfectly in IE and
other ftp tools, and totally impossible to tell them that their Microsoft
ftp server is buggy when it's been working perfectly for ages.

I'm obviously not an expert like you, but if there was no benefit, why is it
supported by these tools ?

> [PATCH]
>> With this change, the prefixed url works fine.
>
> I will not accept an unconditional check like this. It will effectively ruin
> for users who atually have a dir in their home dir named as their own user
> name. Like if I have a dir named 'daniel' and login with 'daniel' on my host!

OK maybe there is a better way to do this, that is check the error code on
the first CWD, but I believe this requires a change in the API. Do you have
any suggestions ?

>> By the way, why is the dir stored in ftp->entrypath prefixed with '/' ?
>
> Because the entrypath is full absolute path to where curl entered the server.
> It is /-prefixed so that it can easily change to that path.
>
>> I don't think the following code (also in ftp_perform):
>>
>> if (conn->bits.reuse && ftp->entrypath) {
>> if ((result = ftp_cwd_and_mkd(conn, ftp->entrypath)) != CURLE_OK)
>> return result;
>> }
>>
>> can handle this, can it ?
>
> Why not? I believe curl works with quite a lot of ftp servers...

It does indeed. I was just asking, because all the CWD commands I've
followed do not have the prefix, so I was wondering what happens when you
issue "CWD /dirname" rather than "CWD dirname". Does it go up in the
hierarchy ?

If so, maybe the FIRST call to ftp_cwd_and mkd in ftp_perform should include
the '/' prefix, or at least try it ?

Daniel, I'm very impressed by the work you've done, but I'm stuck with this
problem. I believe the bug is in the Microsoft ftp server, which means there
is a huge benefit for everyone to find a workaround.

-------------------------------
Eric VERGNAUD - JLynx Software
Cutting-edge technologies and
services for software companies
web: http://www.jlynx.com
-------------------------------
Received on 2004-05-13