On Thu, 13 May 2004, Eric VERGNAUD wrote:

(since we are discussing libcurl internals and since you are using libcurl
anywau, I suggest we move this thread over to the libcurl mailing list and I
cc this reply over there)

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

Then I must agree with Kevin that you would be better off by prepending the
path with a slash and work with absolute paths instead.

> The url I query IS an absolute url. It looks like the following:
>
> ftp://justinkahn:tiptoe@ftp.myserver.com/justinkahn/somedir/someotherdir/

That is not an absolute path. The slash that divides the server name and the
path is not used in the path name, it is just a divider. If you want to use an
absolute path you should use

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

or if you want to adhere to the RFCs:

 ftp://justinkahn:tiptoe@ftp.myserver.com/%2fjustinkahn/somedir/someotherdir/

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

Correct. When you specify a path in an FTP URL, the path is tried from the
entering point. If you want an absolute path, you must prefix it with a slash.

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

The only somewhat sane patch that possibly could make sense, would be to first
try to CWD to the directory name as today, and if the first CWD fails, it
could instead try it slash-prepended. That way, it would work as today unless
you use the weirdo MS-style which then also works.

> Please understand that the only goal here is to provide compatibility with
> existing tools and habits, not only with RFC.

I understand that, and while I refer to the RFCs I too want libcurl to work as
the main tools already do and we already knowingly side-step the RFCs on
several occations just because of this.

But I need a good explanation and a proper discussion first, so that we can be
sure that we have researched the problem properly and thought about most
aspects before we proceed and violate another RFC.

Please don't take my sometimes harch tone as anything personal. I think we
both basicly want the same thing.

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

I suspect hey support this just to avoid having to explain or describe the
differences between relative and absolute paths in FTP URLs...

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

That API is only lib-internal and we can modify that at will without anyone
getting sorry.

I think the if-first-CWD-fails-then-try-a-slash-prefix-path-CWD approach could
work. What do you think?

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

It then starts from the root.

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

I think they support this weirdness in the FTP server to allow people to
contninue using bad FTP URLs.

The RFC way of specifying an absolute path in a FTP URL means using that %2f,
which is rather user-unfriendly.

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