tower-http
tower-http copied to clipboard
tower-rs
Decompression service decompress the request
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?
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.
@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). https://github.com/fetlife/tower-http/commit/f2843286d31c08b755c3c983b003fa736859c666
It doesn't handle the unsupported content-encoding though.
I think we have to add a new middleware. Changing the trait bounds like that is a breaking change.
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?
