On Tue, Mar 09, 2010 at 01:48:29PM +0100, Olaf van der Spek wrote:
> 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.

Daniel suggested that others share their opinions about your idea. I'm
explaining how our system currently works, as evidence to why sending a
full Accept-Encoding header would be problematic for existing users of
libcurl.

If "identity" is worse than no header, please at least offer some
evidence as to why.

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

Maybe, but that's not the point. We all have to exchange data with
servers that, like the one I have to use, have a naive concept of how
and when to use compression. We're using CherryPy 3.X, if the
accept-encoding header specifies a type of encoding that the server
supports, it will make a best effort attempt to compress the data.

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

Except that's not true. In the situation that I've described, your
proposed change only adds complexity.

> > Enabling compression by default isn't necessarily going to increase
> > performance by default.
>
> You mean in all cases? Or on average?

I mean that it's situational, and depends upon the conditions in the
network.

> > On low-latency high-bandwidth links, this may even cause performance
> > to decrease.
>
> There's a difference between accepting compression and requiring compresion.

For some servers, yes. But in other cases, stating that compression is
accepted is enough to have the server attempt to compress every
response.

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