Feature Request: content-encoding: zstd

[logankaser]

Major browsers have had zstd support since around mid-2024, and it's starting to slowly become more common,
mostly because of the excellent compression performance.
Personally, I'm interested in it because bevy uses ureq for it's new web asset support, and I have an asset server that can achieve better performance with zstd than what is possible with gzip.

This data is with C libraries, but the Rust implementation numbers are similar:
zlib-rs performance is roughly on par with zlib, the zstd crate is bindings to libzstd.

Library	Ratio	Compress	Decompress
zlib 1.3.1 -1	2.743	105 MB/s	390 MB/s
zstd 1.5.7 -1	2.896	510 MB/s	1550 MB/s

https://caniuse.com/zstd

Anyway, for the short term I'm just going to go with gzip, but I thought, why not let ureq's authors know there is demand?
If you're interested, I could give a PR adding zstd a shot as well.

[algesten]

Hi @logankaser

I suspect you can achieve this with making your own middleware. You modify the request to set the correct accept headers and then make an adapter to stream the body through.

I believe it's still quite a niche compression, so let's keep this issue so people can argue for why they want it.

[algesten]

And just to be clear. We don't want a PR for this right now. Discuss and argue here until we reach consensus.

[logankaser]

To future finders of this issue:
There is a pure Rust decompression implementation: https://crates.io/crates/ruzstd for anyone who has to implement this application-side.
Reqwest also has zstd support: https://github.com/seanmonstar/reqwest