On Mon, 28 Apr 2003, David Balazic wrote:

> I tested some URL handling programs for RFC-1738 compliance

Nice and certainly very interesting! Thanks for doing this and thanks for
posting it here!

> including curl-7.9.8-5 ( the one shipped with red hat linux 9, not the
> newest version, I know , but the curl changelogs do not suggest any big
> change in this area ).

I can't recall any either, except for a minor HTTP-related one recently but
that shouldn't matter here.

Not that I ever thought that curl would be perfectly 1738-compliant.

> While curl was one of the best, it still failed 19 test out of 54 test
> cases.

I think your test suite is very interesting, and I would not mind seeing all
those tests added to the curl test suite! ;-)

However, on your page with the summary, I would really appreciate a lot more
details than just FAIL. The questions I get when I read them are: what did it
do? What was it supposed to do?

That would be _really_ useful to us (and most likely to most of the other
projects referred to as well).

> ftp://uel003r2a:333qwe@rcum.uni-mb.si/$el_a%3a[uel003r2a]/WWW/NDA.PNG

I don't want to be a party-killer, but the [ and ] letters are mentioned in
the RFC1738 to be "unsafe" and as such they should be %-encoded. (Section
2.2, page 3.)

> ftp://uel003r2a:333qwe@rcum.uni-mb.si/$el_a%3a[000000]/uel003r2a/STUFF/[uel003r2a.WWW]/NDA.PNG

Again, it would be interesting to see in what way these ones failed.

> ftp://uel003r2a:333qwe@rcum.uni-mb.si/UMB1%3a%3aSYS$SPECIFIC%3a[FAL$SERVER]NETSERVER.LOG;type=a
> (downloaded file has CR+LF instead of LF ; manual /bin/ftp downloads OK)

I don't see how downloading is a RFC1738 issue though. It only defines
URLs... But of course, curl doesn't properly deal with ftp ASCII transfers,
I've noticed before and I believe there's some issue about this mentioned in
the TODO.

> ftp://uel003r2a:333qwe@rcum.uni-mb.si/test/testfile_upasc.txt
> (downloaded file has all content in one line , no CR or LF)

Now you're out on thin ice. I can't see how RFC1738 mandates this to be
ASCII. It says (section 3.2.3) "The entire ;type=<typecode> part of a FTP URL
is optional. If it is omitted, the client program interpreting the URL must
guess the appropriate mode to use." but I can't see how guessing wrong can be
a violation. Or are you referring to something else in the spec that I've
missed?

I notice that you've detected multiple problems with this same reason: you
think it should auto-detect ASCII in a lot of places where it doesn't, and I
don't see what wording in the RFC that makes you correct.

curl always guesses that without a type thing (or a special command line
option), you mean to transfer a binary file.

> ftp://stein:test12@naomi/te1//test.txt
> ( again FTP command CWD with no parameter not handled )

This is one of the most serious ones, IMHO. What is this supposed to do with
the //? Just an empty 'CWD'?

curl is making a short-cut in the path business, since it makes one single
CWD to the full-dir, and not many single ones for each part of the dir. I've
done that on purpose, and so far I've not received a single report from
anyone having problems with this.

> ftp://stein:test12@naomi/te1/%2ftmp/tmp1.txt
> (wrong handling of CWD /tmp)

I think this is another artifact of the same functionality.

> If not instructed otherwise, I will report this bug(s) to the sf.net
> bugtracker system.

I think that could be good, so that we don't forget it. I don't think we will
(at least I won't) even try to fix all of them within the nearest time period
though.

Any possibility you can make the report more detailed then?

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf