On Mon, 29 Sep 2003, DAVID BALAZIC wrote:

> /* we skip empty path components, like "x//y" since the FTP command CWD
> requires a parameter and a non-existant parameter a) doesn't work on many
> servers and b) has no effect on the others. */
>
> c) "CWD " returns to the login directory on some servers.

Right. I guess it could also do something else on certain servers. RFC959
doesn't tell.

> I say it should be implemented :
>
> a) "doesn't work on many servers"
> If the user supplies a nonworking URL that is his fault.

True.

> On the other hand, some server act on "CWD " and curl now fails to retreive
> perfectly valid URLs from such servers ( URLs that have empty components,
> example:

I disagree a bit. RFC1738 defines that each part should be sent off with CWD,
but RFC959 states that CWD *requires* a path. So, sending a CWD line without
one means we break RFC959-compliance.

The question is then, the "perfectly valid URL" that contains a blank path
part between two slahes, what is that REALLY expecting the user-agent to do?

I figure that you by "perfectly valid" mean that the URL works with your
favourite browser? I acknowledge that we should strive at behaving similarly.

> b) "has no effect on the others"
> So what is the problem if empty components are supported ?

The "problem" we fixed with this, is that a) we again support the //-prefix to
get to the root dir that was broken and b) we don't issue non-compliant FTP
commands to servers.

> To conclude, I request supporting empty path components, because :
> - otherwise some valid URLs do not work

But are those REALLY valid URLs to start with? If so, can you please tell me
what standards you base this on? And do they work like that using the common
browsers?

> - there is no harm caused, there aren't any downsides of supporting them

I would say that the breakage of the //-prefix caused a lot of noise all over
and turned out to be a really bad idea. So, no matter what we decide to do
with //-pieces in FTP URLs, the initial one needs to be dealt with specificly
to make it possibly to specify the root dir that way.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf