content-encoding negotiation should be disabled when the response headers already contain content-encoding

[derek-zhou]

If the response has content-length but not content-encoding, Bandit will go ahead to compress the response body, but leak the original uncompressed content-length. This results in client seeing the response as truncated.

If the response has content-encoding as gzip already, Bandit seems to do a second compression.

Ideally, Bandit should detect the presence of content-encoding in the response header, and skip compression if it is present. When there is no content-encoding in the headers, Bandit should remove the old content-length header, if any, and replace it with the compressed content-length.

According to:

https://ninenines.eu/docs/en/cowboy/2.6/manual/cowboy_compress_h/

Cowboy does it. As of now, I have to disable compression globally, which is sub-optimal.

[mtrudel]

Yep, agreed that this should be better handled as you suggest. I'm also having to be more aware of the returned headers (specifically Connection: close) for the issue underlying #149, so I'll make sure to fold both of these into a consolidated solution coming the next release (a few days away, I think).

Thanks!

[mtrudel]

Slated to be fixed in #165

[mtrudel]

Fixed in #165. Please reopen if further work here is required!