compression support out of the box?

[jakswa]

Are there plans to allow response compression out of the box? As an example of what I mean, I've used this middleware in small projects that use axum and allow tower HTTP middleware.

The result would be that you get headers like this on your big HTML responses:

Content-Encoding: gzip

I was very impressed with the feature list on this framework out of the box and low dependency count (anything to help rust compilation times 😩). The one random side project I like to rewrite to test out frameworks like this just happens to benefit from compression, since it targets mobile devices and has a beefy HTML landing page. So I thought to ask. No worries if it's out of scope.

[levkk]

Hi there,

As a quick workaround, you can always put nginx in front of this (or any other) framework with gzip enabled. A reverse proxy with nginx (or something else) is typically trivial to setup and operate.

That being said, I can't think of a reason why we wouldn't add support for compression. The crate for this I reckon would probably be flate2 (don't think we want to implement gzip ourselves). One minor thing to consider is, if we were to add TLS (which I'd like to do some day as well), we need to make sure both are not enabled at the same time.

Rwf middleware supports modifying both requests and responses. The latter isn't well documented, but there are examples in the code, e.g. RequestTracker middleware. So implementing gzip (or any other algorithm) should be very doable.

Cheers!

[jakswa]

Good vibes and makes sense. And good callout with adding an nginx proxy. I've seen it in other cases, even if I'm not interested in maintaining that in front of this tiny service. My case might be an edge one -- weirdly I think even a few ms would have a significant impact on response times for this toy project I track:

[levkk]

Sounds good.

PRs are welcome, if you have a moment! Let me know if you have any questions. I'm comfortable adding flate2 as a mandatory dependency, so I don't think we need to gate this behind a feature.

Couple of thoughts on implementation:

• Gzip is CPU intensive, so we should think about using tokio::task::spawn_blocking.
• We need to parse the Accept-Encoding header to automatically figure out if compression is supported. Since flate2 supports both gzip and deflate, we can support both.

Cheers!