Daniel Stenberg wrote:
>
> 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!

I forgot to note in my first message : I am not subscribed, so please
CC me on your replies. This also means that my post will appear delayed
on the mail list. I case some one forgets to CC me, I will monitor the
web archive.

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

I can't see why would anyone write a program that does not implement
the standards it pretends to support. Especially such a simple thing
as FTP URLs...

>
> > 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?
It failed. ( did not download the specified file )

> What was it supposed to do?

Download the specified file.

:-)

In most cases the following happened :

URL : ftp://ftp.example.com/a/b/c

Should do :
<connect and login to ftp.example.com>
CWD a
CWD b
GET c

Did do :
something else ( it should be clear from the sources what it does , no ?
)

I will try to get some samples with the -v or --trace option.

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

yes, but I did encode it some cases and it did not help much.
Also this matters only to the client program and I used the -g option to
turn off their special meaning.

But you are right. Maybe I will revise that tests...

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

Will post later.

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

If it is a known bug, then OK.
 
> > 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?

No, you are perfectly right. But I think it is not too much to expect
that
guessing the type of file whose name ends with ".txt" succeeds as ASCII.

I wouldn't implement such guessing in my programs either :-)
 
> 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.

No problem. It is after all guessing, so you can't say what is correct
and what not.
 
> > 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'?

Yes, at least that is how I understand the RFC.
section 3.2.2 , page 7 :

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

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

I will generate traces ( or is "-v" enough ? ) and send them later.

Sincerely,

-- 
David Balazic
--------------
"Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore
Logan
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf