Yavor,
Your Jira account is now open.
Gary
On Wed, Jun 18, 2025, 08:40 Stankov. Yavor <y.stan...@seeburger.com> 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 <ol...@apache.org>
> Sent: Wednesday, June 18, 2025 3:23 PM
> To: HttpClient User Discussion <httpclient-users@hc.apache.org>
> 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(contentDecoderMa
> > 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: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
