async-http-client
async-http-client copied to clipboard
AsyncHttpClient
Brotli support
At the moment, there's no Brotli support. Looks like Brotli support was intentionally dropped in commit 420b017bbb36e881cde91bdc7975ac1893c5468e.
Is there still a reason to not support it? If no, then it may be a good idea.
An example of decompressing Brotli can be found in https://github.com/AsyncHttpClient/async-http-client/issues/1759.
@oripwk There isn't a core reason that I know of, but would have to investigate a bit further before committing to changing it. This is, however, ~now~ not (unfortunate typo) high on the priority board at the moment (CI, docs and other niceties are a bit more urgent IMHO).
Please feel free to ping me if I don't get back to you on this, though.
Making a mention of this repo here for later: https://github.com/hyperxpro/Brotli4j
@hyperxpro Considering using your lib for AHC, in order to add Brotli support. If you've got a bit of time to give some pointers or your thoughts on the topic that would be awesome. If not, just a FYI that I'm considering it:)
Just wondering, why not use Apache commons-compress directly? It will spare you one additional dependency.
@oripwk There's no specific reason to use brotli4j. I did not investigate thoroughly yet - that lib just caught my eye since @hyperxpro contributed to Gatling (and the previous maintainer is the creator of Gatling).
Thanks for the heads up!
@TomGranot My library is pretty straight forward so you will not face any difficulty while using it. Just a heads up for chunk content, you should consider using DirectDecompress. You can pass in chunks and get the status of decompression. If the status is NEEDS_MORE_INPUT then you need to aggregate chunks (up to 16 MB).
@oripwk Commons-Compress is outdated for Brotli and it only supports decompression but Brotli4j supports both compression and decompression.
@hyperxpro Excellent. Will take a closer look and come back if I need anything else:)
Adding some niceties to look at later:
https://github.com/netty/netty/pull/10626 https://github.com/hyperxpro/Brotli4j/issues/2 https://github.com/gatling/gatling/commit/934885be192afba56af3ec3e388e269a04b2ed1c
Also - note that the currently used version of Netty only supports GZIP and DEFLATEdecompression. The right path is probably extending this decompressor and adding Brotli support there, then removing the filtering out of all br content encoding.
We will also of course need an actual decoder (a la ZlibDecoder), and (need to validate this) Brotli4J might help.
Any chance this could be revisited? It look like Netty 4.1.64.Final supports Brotli, and there are MANY reasons to update the default version of Netty up to a more recent version.
Any chance this could be revisited? It look like Netty 4.1.64.Final supports Brotli, and there are MANY reasons to update the default version of Netty up to a more recent version.
Will do a PR by weekend but looks like AHC is not maintained anymore.
Sad to see the project is not maintained anymore. It's the only async HTTP client in Java and it's used by a lot of projects. It's kind of unbelievable.
I'm reaching out to @TomGranot to become AHC maintainer and revive this project.