On Mon, Mar 8, 2010 at 11:24 PM, <johansen_at_sun.com> wrote:
> I'd like to speak out against such a change.  While I realize some
> applications would always benefit from the use of compression, there's
> no way to guarantee that it's always a sensible default.  If libcurl
> doesn't send any accept-encoding header and it is desirable to send one by
> default, my suggestion would be to use "identity" as the default.

That's worse than sending no header.

> The data transferred by our application is already compressed, but the
> metadata is not.  Our application sets this header when it's requesting
> metadata, but not data.  In most cases, the requested content is already
> compressed, and it would be counterproductive to have the server try to
> perform a second compression as part of the download.  It is
> straight-forward to write a per-application function that sets up the
> defaults on easy handles.  That's what we did for our application.

The header tells the client what encodings it accepts/understands.
It's not supposed to be a mechanism for the client to tell the server
whether it's a good idea to compress the content.

In your case, the server should know whether it's a good idea to compress.

> I don't see what's wrong with having an application explicitly request
> the features that it desires.

Global code complexity...

> Enabling compression by default isn't
> necessarily going to increase performance by default.

You mean in all cases? Or on average?

> On low-latency
> high-bandwidth links, this may even cause performance to decrease.

There's a difference between accepting compression and requiring compresion.

Olaf
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-03-09