Misleading Content-Encoding Header in Default-Setup for Request Compression

[AndreTeigler]

Describe the bug
When the openfeign request compression is used the the FeignContentGzipEncodingInterceptor adds two values to the header:

addHeader(template, HttpEncoding.CONTENT_ENCODING_HEADER, HttpEncoding.GZIP_ENCODING, HttpEncoding.DEFLATE_ENCODING);

The compression itself is dependent on the used client. The feign default client (https://github.com/OpenFeign/feign/blob/master/core/src/main/java/feign/Client.java) can either use gzip compression or deflate compression. If both headers are present it will currently choose gzip but the headers remain unchanged.

According to the Content-Encoding documentation (https://datatracker.ietf.org/doc/html/rfc2616#section-14.11) the header indicates that both compressions have been applied. The default client only applies one so the receiving server (if it handles the Content-Encoding header correctly) will first try to decompress with defalte which fails.

Sample
Can be reproduced by using a simple spring boot app using spring-cloud-starter-openfeign and setting up a client which will sent a body with request compression. The headers will contain Content-Enconding: gzip, deflate but the compressed body will only be gzip data.

[OlgaMaciaszek]

Thanks @AndreTeigler, makes sense; we can't know which client and which setup will be used in the app configuration, however, we should allow the users to apply a more fine-grained configuration via properties.

[AndreTeigler]

@OlgaMaciaszek
I could provide a pull request over the next weekend by just adding another configuration property for the encoding header. It defaults to gzip, deflate to keep backwards compatibility but would allow to set the header to the appropriate value for the setup in use.

[OlgaMaciaszek]

Thanks @AndreTeigler. Sounds good.