Re: Unknown/invalid Content-Encoding response header

2017-02-06 Thread Oleg Kalnichevski
On Mon, 2017-02-06 at 12:10 +0100, Oliver Stöneberg wrote:
> A few days ago I wrote some test for some code I am using HttpClient 
> in. The current code is using 4.5.2. After I finsihed the tests I 
> backported those to anolder version of the compomonent I am using
> the 
> library in which still uses 4.3.x. The tests worked fine with the 
> latest version, but with the older one I got the following exception:
> 
> Caused by: org.apache.http.HttpException: Unsupported Content-Coding: 
> UTF-8
>   at
> org.apache.http.client.protocol.ResponseContentEncoding.process(Respo
> nseContentEncoding.java:98)
>   at
> org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttp
> Processor.java:139)
>   at
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java
> :200)
>   at
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
>   at
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java
> :108)
>   at
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttp
> Client.java:184)
>   ... 37 more
> 
> It turns out some part of the code was using "Content-Encoding" to 
> specify the charset of the response content. It feels a bit strange 
> to me that a newer version would not report such a serious error. I 
> looked at the code in question and I can see that 
> ResponseContentEncoding.java change quite a bit and now has an 
> "ignoreUnknown" flag for these cases - unfortunately that appears to 
> be hard-coded to "true" now and cannot be configured.
> 
> I browsed the release notes for some insight on this and it appears 
> to be that the fix for 
> 
> * [HTTPCLIENT-1550] Fixed 'deflate' zlib header check.
>   Contributed by Oleg Kalnichevski 
> 
> caused this change in behavior. Seems to me like the fix went a bit 
> too far on this.
> 

See HTTPCLIENT-1643 for details

https://issues.apache.org/jira/browse/HTTPCLIENT-1643

Oleg

-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org



Unknown/invalid Content-Encoding response header

2017-02-06 Thread Oliver Stöneberg
A few days ago I wrote some test for some code I am using HttpClient 
in. The current code is using 4.5.2. After I finsihed the tests I 
backported those to anolder version of the compomonent I am using the 
library in which still uses 4.3.x. The tests worked fine with the 
latest version, but with the older one I got the following exception:

Caused by: org.apache.http.HttpException: Unsupported Content-Coding: UTF-8
at 
org.apache.http.client.protocol.ResponseContentEncoding.process(ResponseContentEncoding.java:98)
at 
org.apache.http.protocol.ImmutableHttpProcessor.process(ImmutableHttpProcessor.java:139)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:200)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
... 37 more

It turns out some part of the code was using "Content-Encoding" to 
specify the charset of the response content. It feels a bit strange 
to me that a newer version would not report such a serious error. I 
looked at the code in question and I can see that 
ResponseContentEncoding.java change quite a bit and now has an 
"ignoreUnknown" flag for these cases - unfortunately that appears to 
be hard-coded to "true" now and cannot be configured.

I browsed the release notes for some insight on this and it appears 
to be that the fix for 

* [HTTPCLIENT-1550] Fixed 'deflate' zlib header check.
  Contributed by Oleg Kalnichevski 

caused this change in behavior. Seems to me like the fix went a bit 
too far on this.


-
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org