Spring Cloud Openfeign Misleading Content-Encoding Header in Default-Setup for Request Compression

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.

Comment From: 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.

Comment From: 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.

Comment From: OlgaMaciaszek

Thanks @AndreTeigler. Sounds good.