Document which Accept-Encoding lib-http-client supports

[ComLock]

Does it support all the ones mentioned here? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding

• [ ] gzip
• [ ] compress
• [ ] deflate
• [ ] br
• [ ] identity

[rymsha]

I guess (meaning, not official):

• if you provide any Accept-Encoding - you are on your own. lib-http-client won't help you to decode the body.
• out of the box lib-http-client will add Accept-Encoding: gzip

[ComLock]

'*' is listed as the default here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding

Perhaps it's worth mentioning that we have "overridden" the default?

BTW. Was this changed recently? Say in 2.4.0?

It could simply be that the remote server now supports gzip, and my code doesn't handle that, yet.

[ComLock]

Do we have any app using http-client and handling gzip? Could not find any lib on Enonic market that handles gzip... I do have some Java code handling an actual ZIP file on filesystem, but nothing taking a stream/string.

[rymsha]

This is the default value if the header is not present

Well, It is present when you don't provide your own, because:

out of the box lib-http-client will add Accept-Encoding: gzip

Do we have any app using http-client and handling gzip?

But why, when http-client does it for you transparently?

[ComLock]

Soooo, it handles it transparently (unzips the gzip) when you don't provide the header, but if you provide the header as gzip you get a gzip string which is NOT unzipped? Because I get a bunch of ���� as in binary string, when I provide the header...

[rymsha]

lib-http-client is a wrapper on top of https://square.github.io/okhttp/ It says:

Transparent GZIP shrinks download sizes.

And you fell into this https://github.com/square/okhttp/issues/2132#issuecomment-169500736

The moral of the story: don't mess with http headers

[rymsha]

will be fixed with #89