On Tue, Oct 30, 2018 at 09:51:30AM +0100, Daniel Stenberg wrote:
> Changing the default to use '--compressed' by default might also improve life
> for a bunch of users since it might save bandwidth and can reduce transfer
> waits (since it'll need to transfer less data to get the job done).

For the record, I was originally thinking that curl should just do the
decompression part by default, not necessarily *request* the compression
by default. (i.e. it would keep the current default of not sending a
Accept-Encoding header, but would decode any reponses that were
content-encoded anyway).

> I can't think of any middle-way approach for this change that would make the
> transition easier. It seems to be rather binary.

I thought about this a bit more, and another option is to have the
default request send 'Accept-Encoding: identity' to discourage servers
from sending the response encoded. However as you say many users might
benefit from the compression in terms of bandwidth savings and so in
that case defaulting to --compressed might be a better option.

In any case it sounds like (from your comment on the Github issue) that
it's possible to build curl without support for --compressed, and in
that case it probably does make sense to send 'Accept-Encoding:
identity' explicitly. In that scenario use of --compressed is not an
option, and setting this header would be an accurate representation of
what the client side can handle in terms of content-encodings.
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-10-30