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.

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.

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

> 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.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf