On Thu, 11 Mar 2010, Olaf van der Spek wrote:

>> Are you asking people to change existing, stable code which works fine
>> right now? That may be fine if the original developer is still around, not
>> so fine if the remaining developers treat libcurl and the code which
>> accesses it as a black box.
>
> No, I'm asking people to fix their server configs.

That might be a worthy goal for someone to fight for, but it is not the job of
libcurl as I see things. On the contrary, libcurl is designed and intended to
be conservative and mostly just get out of your way and getting the things
done.

We adapt to the surroundings rather than expecting the surroundings to adapt
to our needs or even our interpretations of specs and standards. Instead we
see what is currently done and we follow.

Another general design concept is that libcurl does very simple requests by
default and offers options to allow clients to enable fancier behaviors. Such
as using a User-Agent field, using compression, using authentication, using
cookies and more. By being consistent in this regard, users can expect certain
behaviors even when they haven't previously thought about them. An author of
an app that uses libcurl should know that libcurl only does the basics and if
nothing else is enabled, it will do nothing else. I think it is of great
value for us to stand by this "promise". It makes us solid and trustworthy.

> Again, IMO, that's a server-side bug. If apps fail due to this, it might be
> a good idea to fix stuff regardless.

Most client-side app authors cannot affect the server side apps, their bugs or
setup issues. They need to live with them.

In this discussion, I've only seen one vote in favour if enabling compression
by default and that's yours.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html