Feature proposal
Instead of defaulting HTTP transfer encoding to gzip, have it configurable and allow other types of compression.

Context

Right now, golang's http framework by default and silently (not visible in GIT_CURL_VERBOSE!) adds Accept-Encoding: gzip to requests. This can make an LFS server send gzip-compressed data.

I stumbled upon a case where the LFS servers were spending more than 60% of their time doing CPU-bound gzip compression. LFS servers should have high egress, and generally be bounded on network egress.

I experimented with other compression algorithms using -c http.extraheader="accept-encoding: zstd" and it generally worked, but it perhaps would be better if it was just an lfs config, not git-wide?

Details

Have lfs.acceptEncoding which will accept a comma-separated list, resulting in Accept-Encoding header being set in the HTTP requests git-lfs is making for download and upload urls. Batch endpoints will remain unaffected.

E.g. lfs.acceptEncoding=gzip,zstd will result in Accept-Encoding: gzip,zstd being added.

golang's http lib supports zstd, so not having it shouldn't be a problem.

Potential extension of this could include preferences using weights like Accept-Encoding: gzip;q=1.0, identity;q=0.5. It's pretty much a standard

Questions

Does it make sense to do it just for git-lfs, or is it better (and safe) to use git-wide http.extraheader="accept-encoding: zstd" config?

My thinking is it's better to target the requests that would benefit from this the most - download requests. If so, this has to be done via config in git-lfs.