On Thu, 13 May 2004, Eric VERGNAUD wrote:

> 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?

> 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?

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.

> However it seems that Microsoft users are used to enter the prefixed url.

> Both urls

What both URLs?

> work fine with Internet Explorer on Windows and MacOS X and with Transmit on
> MacOS X

What about Mozilla?

> 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?

[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!

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

-- 
     Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
      Dedicated custom curl help for hire: http://haxx.se/curl.html