le 14/05/04 8:34, Daniel Stenberg à daniel-curl_at_haxx.se a écrit :

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

Ok I'll work on a Microsoft specific patch and let you know.

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