Content coding support

[ok2c]

Relatively minor code optimization that improves consistency of automatic content decompression by the classic and async transports. @arturobernalg Please double-check.

[arturobernalg]

@ok2c per RFC 9110 (§8.4) Content-Encoding lists codings in apply-order, so we should decode right→left (hence the reverse loop) — can you confirm that’s still your expectation here?”

[ok2c]

@ok2c per RFC 9110 (§8.4) Content-Encoding lists codings in apply-order, so we should decode right→left (hence the reverse loop) — can you confirm that’s still your expectation here?”

@arturobernalg I made a mistake. Good catch. Please take another look.

[arturobernalg]

LGTM

[rpkrajewski]

Funny that this popped up because I am new to using the HTTP5 library, and the HttpEntity.getContent() Javadoc does not say if you get back the encoded stream, or (better) a decoded stream. Does this PR implement a best effort for making HttpEntity.getContext() do the latter? If so, the Javadoc for that function should be clarified.

[ok2c]

Funny that this popped up because I am new to using the HTTP5 library, and the HttpEntity.getContent() Javadoc does not say if you get back the encoded stream, or (better) a decoded stream. Does this PR implement a best effort for making HttpEntity.getContext() do the latter? If so, the Javadoc for that function should be clarified.

@rpkrajewski The classic HttpClient has had support for the transparent content decompression for quite some time. Recently this support has also been added to the async HttpClient.

As to whether an entity content is encoded this is determined by the #getContentEncoding method. I am not sure what else there is to say but we happily take javadoc improvements.

[rpkrajewski]

Thanks - I will experiment more with this when 5.6 is out.