Decompression service decompress the request

[Antti]

Feature Request

Add request decompression to the Decompression service. This would be used on the server-side to decompress client requests, in addition to the existing logic to decompress server responses.

Motivation

In our company, we are using Axum for our internal APIs and posting large JSON payloads. While we are planning to move to some more space-efficient formats, it would help a lot if we could compress the client request body using standard compression methods (gzip, deflate, br).

Proposal

Implement decompression for the requests based on the Content-Encoding header

Alternatives

Possibly create a separate service/layer for this?

[davidpdrsn]

This has been requested before but the question has always been how to handle unsupported encodings.

About content-encoding the spec says

An origin server MAY respond with a status code of 415 (Unsupported Media Type) if a representation in the request message has a content coding that is not acceptable.

So I suppose we could do just do that.

Most of machinery is already there so this is probably not hard.

[Antti]

@davidpdrsn I did manage to make it work for us with the following changes (although 1 example and tests do not compile with some type errors).
fetlife@f284328

It doesn't handle the unsupported content-encoding though.

[davidpdrsn]

I think we have to add a new middleware. Changing the trait bounds like that is a breaking change.

[wanderinglethe]

I have created a branch with decompression middleware for request bodies.

It still needs documentation and refactoring/naming to coexist with the other Decompression middleware.

--

I refactored the decompression module, but I am not sure if this is the correct way. I have renamed Decompression to ResponseDecompression and then exported it as Decompression. But it looks like rust doc does not rename everything.

And to return Unsupported Media Type, would I need a separate ResponseFuture?

[leio]

Given that #282 is merged and released, I think this issue can be closed as well?

[davidpdrsn]

Yes!