On Wed, 2025-06-18 at 12:39 +0000, Stankov. Yavor wrote: > Hi Oleg, > > Thanks for the quick response! I will open a ticket but it will take > some time since I don't have account there and I'm waiting for > approval for one. > > In the meantime, do you see any workaround of this issue, since this > is blocking our update? >
If all you want is to drop 'x-gzip' from the `Accept-Encoding` header value, add a request interceptor or a request exec handler that rewrites the `Accept-Encoding` header. Oleg > Best Regards, > Yavor > > -----Original Message----- > From: Oleg Kalnichevski <[email protected]> > Sent: Wednesday, June 18, 2025 3:23 PM > To: HttpClient User Discussion <[email protected]> > Subject: Re: The Accept-Encoding value has changed after update to > Apache HTTP Client 5.5 > > On Wed, 2025-06-18 at 12:05 +0000, Stankov. Yavor wrote: > > Hi, > > > > I just saw that the requests sent by the HTTP Client 5.5 has change > > in > > the Accept-Encoding value from: gzip, deflate to: gzip, x-gzip, > > deflate. > > > > I checked the code and the change is coming from the constructor of > > the ContentCompressionExec which now no longer takes in mind the > > parameter acceptEncoding. > > This is a bug. Please raise a ticket in JIRA for this defect. > > Oleg > > > > > > This constructor is called by the HttpClientBuilder which is > > passing > > the acceptEncoding parameter by using the values from the > > contentDecoderMap for which there is a setter in the builder which > > we > > use and we rely on having exactly these values for the header: > > > > LinkedHashMap<String, InputStreamFactory> contentDecoderMap > > = > > new LinkedHashMap<>(); > > contentDecoderMap.put("gzip", > > GZIPInputStreamFactory.getInstance()); > > > > contentDecoderMap.put("deflate", > > DeflateInputStreamFactory.getInstance()); > > > > > > HttpClientBuilder.create().setContentDecoderRegistry(contentDecoder > > Ma > > p)... > > > > > > > > I know that x-gzip is a legacy value for gzip and it is most > > probably > > added for compatibility reasons only and it should not have huge > > affect, but I'm afraid that we are calling a lot of different > > servers > > some of which are using other HTTP based protocols and I don't > > really > > know if this could affect out processing. > > > > So the question is - is this a bug - since the constructor is not > > deprecated (ContentCompressionExec) but the value is not used > > anymore > > (acceptEncoding)? Or if not and this will be the behavior in the > > future, what is the best way to override this behavior? > > > > Best Regards, > > Yavor > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
