-
Notifications
You must be signed in to change notification settings - Fork 185
Request decompression #282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request decompression #282
Conversation
Still needs some refactor to remove duplicate code and needs documentation
Which either polls its inner future or returns 415 Unsupported Media Type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't read through the code yet and while I appreciate that you wanna refactor I would prefer if it was done in a separate PR. Makes it easier to review and bisect in case of bugs.
Is it possible for you to split things up?
Of course, where should I locate the request decompression module and what should I name it? |
I'd call it |
I think we should also consider making separate middleware for (de)compressing requests and responses rather than making one middleware do both. It's easy to apply both if that's what users want. |
That is what I have done, right? |
Refactoring of `decompression` module will be done in a later PR
Yes sorry. It was mostly a note to myself. Haven't actually read your code yet 😅 |
I think most of the PR is completed and can be reviewed. Although my questions, in the first message, still stand. Thank you |
Thanks! I'm not sure when I'll get time to review this. Going on vacation in a few days. So might not get time before I'm back in a few weeks. |
Have a good vacation. I will see if I can work on some other PR or maybe I will take some vacation as well. :) |
@davidpdrsn any chance you are back from vacation? 🙏 I'd also hugely appreciate getting this merged ❤️ |
I am 😊 I'll try and have a look soon. |
Thank you |
@davidpdrsn Thanks! Hope you had a lovely vacation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Do you have any critique on conventions, design or anything else?
|
I still wanna look through. Please remain patient. |
Thank you. That's what I expected, but maybe @Nehliin has some critique as well |
Any progress on getting this merged? At my workplace we have a need to support request decompression in our Axum/Hyper based services, and it would be much better if we get support from that in |
Apologies if this question is asking the obvious. Would it be possible to specify the maximum permitted request body size after decompression in a lazy way somehow, ie. without uncompressing the whole payload, as to avoid excessive memory consumption? |
@mmd-osm As far as I can tell, this is doing streaming decompression, so you should be able to apply a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for taking forever to review. First round of feedback is in! Generally I think this looks good. Mostly minor nitpicks here and there.
} | ||
|
||
/// Passes through the request even when the encoding is not supported. | ||
pub fn pass_through_unaccepted(mut self) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this method should take a bool
to similar to the set_*
methods.
Then users can easily configure things based on things like env vars:
layer.passthrough_unaccepted(std::env::var("FOO").is_ok())
I believe it is also spelled passthrough
and not pass through
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my native language it would also be passthrough
, but in English that is a noun and the verb is to pass through
.
Oh and CI should be fixed if you merge the latest |
Thank you for reviewing David. I have made the changes you requested. |
Would be amazing to see this merged :) thanks for the effort @wanderinglethe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! Sorry for taking so long to review it.
Motivation
Currently compression and decompression of response bodies are supported with the
Compression
andDecompression
services. Issue #276 proposes to also implement decompression for request bodies, this PR addresses that. To complete the compression and decompression modules, request compression could be added in another PR.Solution
RequestDecompression
decompresses the request body with the algorithm defined in theContent-Encoding
header, it does not support multiple/stacked algorithms. When an algorithm is not supported it will return a415 Unsupported Media Type
by default, but it can also be configured to pass-through the request to the inner service.Questions
This is my first PR and I am not sure if I am going in the right direction, I would already like some feedback while working on the issue.
Refactor
decompression
moduleWill be done in a different PR.
Service and Future implementation
The service and future are based on the
Decompression
service andResponseFuture
, but I have the feeling the constraints are too complex. Can these be simplified?And the same for the boxing of the bodies and errors, has this been done correctly?
API
I have copied the layer implementation from the request decompression layer to make the API uniform. The extra functionality is the pass-through of unsupported encodings, maybe later this can be changed into a single final decompression, that return the 415, and a stacked decompression that pops an encoding and pass-through to the next service.
Would this be a good first way to go?
General code style / conventions
Since I have the basic functionalities tested I can now refactor code. Are there any structures that can be written clearer or more concise? Or are there things that do not follow Rust or Tower conventions?
Todos
decompression::Decompression
, including docsThank you
Thank you for looking into this.