Daniel Stenberg wrote:
>
> On Tue, 29 Apr 2003, David Balazic wrote:
>
> > > 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...
>
> This is a very arrogant thing to say. Downright rude.

Sorry.

> curl is yet another project in which all development is taking place during
> people's donated spare time. We fix problems, we make it work, we deal with
> it. No one gets paid.
>
> In this case, no one has experienced any problems with FTP URLs or at least
> no one has reported any. And no, no one has written any test suite set for
> all those strange-looking FTP cases you fed curl with. We've had a pragmatic
> approach to standards and development during curl development. What works is
> fine, what doesn't work we fix.
>
> If you think FTP URLs are so easy and making a tool completely RFC1738-
> compliant is a piece of cake, then please provide the patches. I would very
> much welcome them.
>
> > 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
>
> Yups, this is not by accident. I've made libcurl act like this on purpose to
> reduce the amount of FTP command-response interactions, and while I've known
> it is RFC-violation, I've found it to work for a very long time and as I said
> above, no one ever filed a bug report on this.
>
> So, the question arises: are theoretical bugs (rfc-violations) worth to fix
> if they make some other areas do worse? In my eyes: no, not until we find out
> a case that proves it needed to fix.

What would be worse if doing separate CWD's ? Slower operation ?

> As a comparison, we've deliberatly broken against several RFC statements in
> other places in the curl code, only because that is how other common
> user-agents do and because that is what people will assume curl to do.
>
> Using your excellent test report as input, I might get motivated to start
> working on getting it more compliant.
>
> > > 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.
>
> I realize that, it was just that you've written up a test case to test
> applications against RFC1738 and then you feed lots of non-compliant URLs to
> the applications...

You are right, I will change that part of the test.

>
> > Also this matters only to the client program and I used the -g option to
> > turn off their special meaning.
>
> Why does this only matter to the client program? curl is documented to accept
> one or more URLs, those URLs are passed on to the library and taken care of
> there. Passing in illegal letters to the client program will make them
> illegally passed on to the library.
>
> But of course, curl and libcurl has no problems with the [] letters (the curl
> tool might if you don't use -g of course) in URLs anyway.
>
> --
> Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.

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