On Mon, Mar 8, 2010 at 11:24 PM, <[email protected]> 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
