Could you do a benchmark for how this influences actual file transfer performance? Does it also influence for instance large incompressible files and then how's the performance I wonder?

@svenstaro You are right. There is regression when downloading big file. I do the following test with curl downloading 10GB file. When using compressed flag, the time spent increase from 16s to 56s. Although the internet transmission size will be considerably smaller, but the transmit speed penalty is too large and the result is way slower than before.

I think we should add compress as an option and let users decide whether to enable this or not. IMO, there would be some cases when the internet bandwidth is scarce or the users would like to control the compression behavior through accept-encoding.

Test result is attached below.

# Test 1 (Master)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10.0G  100 10.0G    0     0   612M      0  0:00:16  0:00:16 --:--:--  617M

# Test 2 (Compress-response w/o --compressed)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10.0G  100 10.0G    0     0   618M      0  0:00:16  0:00:16 --:--:--  624M

# Test 3 (Compressed-response w/ --compressed)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 46.5M    0 46.5M    0     0   847k      0 --:--:--  0:00:56 --:--:-- 2334k

I'd be fine with adding a flag (and test) that conditionally enables compression. The help text should also explain that for fast connections it'll likely make transfers slower depending on CPU. Definitely off by default.

This will be closed and will open a new PR if the option version is ready. Thanks for the suggestion.