Hi Gary, Thank you for the quick reaction.
Here is the bug I've opened https://issues.apache.org/jira/browse/HTTPCLIENT-2376 Best Regards, Yavor -----Original Message----- From: Gary Gregory <[email protected]> Sent: Wednesday, June 18, 2025 3:44 PM To: HttpClient User Discussion <[email protected]> Subject: Re: The Accept-Encoding value has changed after update to Apache HTTP Client 5.5 Yavor, Your Jira account is now open. Gary On Wed, Jun 18, 2025, 08:40 Stankov. Yavor <[email protected]> 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? > > 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(contentDecoderM > > a > > 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] > >
