On Sun, 5 Oct 2003, DAVID BALAZIC wrote:

> RFC959 does not say that it can't be an empty string ( is says "system
> dependent file group designator" )

Right, it doesn't say it can't be nothing, but it says that *something* should
follow the CWD command.

The fact that some server authors have interpreted the spec that it requires
an argument is indicating that others have done the same intepretation.

> On the other hand, <URL:ftp://myname@host.dom//etc/motd>, would "CWD " with
> a null argument, then "CWD etc", and then "RETR motd".

That is indeed a crystal clear quote mentioning this exact case.

Still, there's not a single standard anywhere that details what "CWD " is
supposed to do on the server.

Doing a 'cd' back to home dir on "CWD " seems like a totally pointless thing
to do, since all paths start from there anyway. Not that it is relevant to
this discussion.

> > 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.
>
> It means "compliant to definition" instead of compliant to my own idea. We
> all like when MS interprets standards in his own weird way, don't we ?

Listen. If you think standards are always clear, and straight-forward to
follow, and on the other hand that we all always follow them unconditionally
even when do understand them, then wake up.

We need to interpret standards. We need to understand them and do what we
think they mean, and we do need to follow what others do as people will expect
similar behavior from similar tools given similar input.

I, and others involved in curl, have always favoured adhering to standards. Of
course that means we interpret standards in our "own weird way". How can we
avoid that? This very discussion is going on just because of interpretation.

> Last time I checked, MS IE 6.0 could retreive only 2 URL out of 40 I tried,
> failing on simple ones like "ftp://user:pass@server/test.txt", so I can't
> say anything about IE in this regard.

Oh. Then we can't compare with that tool.

> Others ( mozilla, lynx , wget ) fail on ones like
> "ftp://username:password@server.domain.net/subdir_of_login_dir/some_file_there".
> So they can't really be used something as a goal or example IMO.

They all fail on something as basic as that? Odd.

But AFAIR, at least wget supports the //-prefix to reach the root of the ftp
server. (Basicly because it does a CWD to the whole path given to it, like
curl used to do.)

> > 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.
>
> Or you could add "unix like ftp url, familiar to all unix users", like
> the one used in ncftp :
>
> hostname:path , for example(s) :
>
> ftp.luth.se:/pub/something
> ftp.uni-kl.de:index.html

Nah, that is even further away from a true URL and it really doesn't serve any
purpose.

To summarize my stand-point right now:

1. We should make empty path parts equal "CWD " commands.

2. I still want curl to break the above mentioned RFC1738-defined way on the
   first slash, to allow "ftp://host//tmp/" to point out the "/tmp/" dir.
   Lots of people rely on this standard-breach, and other tools support it too.
   If we ever write up a document on what standards we follow and what items
   of them we don't follow, this could be added in there!

3. Not really what we've discussed here, but I would also like to see the
   ftp->dirs array being reallocated if we hit the allocated size so that we
   won't have a maximum dir depth. It would also allow us to make a smaller
   allocation by default.

Now we only need someone to write a patch. :-)

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