-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Make HTTP decompression limit configurable #2203
Conversation
gwynne
commented
Feb 27, 2020
- When using HTTP compression (gzip, deflate), the decompression limit was hardcoded at a ratio of 1:10 (set HTTP request decompression ratio limit #2192). It is now possible to specify a custom limit. The default remains unchanged.
…'s enabled. Kept the default of 10x ratio. Added unit test for compression support and the limit handling.
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 feel like there should be a way to combine both the supportDecompression
and decompressionLimit
parameters, but I can't think of a good way to do it at this point.
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!
@calebkleveter agreed. I can't think of a good way either though. If we find something we can deprecate these methods. |
These changes are now available in 4.0.0-beta.4.1 |
Instead of a Boolean you could use an enum
|
@t089 that's a good idea. An enum-like struct could be even better so that we can add new "cases" in the future. |
* Add the ability to configure the limits of HTTP decompression when it's enabled. Kept the default of 10x ratio. Added unit test for compression support and the limit handling. * Tweak a unit test so it doesn't hang forever on network failures.
* Add the ability to configure the limits of HTTP decompression when it's enabled. Kept the default of 10x ratio. Added unit test for compression support and the limit handling. * Tweak a unit test so it doesn't hang forever on network failures.
@t089 Yeah, I was thinking of something like that, but I couldn't quite put it together in my head without breaking the existing API (which I try to avoid). The enum you suggested looks great, I think it makes sense to just use that instead of trying to stick to API consistency while still in beta (just look at how much Fluent changed in the last few days 😆). |
The best part is that now enum cases with associated values can have default values. |
public struct HTTPDecompressionConfiguration {
public static var disabled: Self {
.init(isEnabled: false, limit: ...)
}
public static func enabled(limit: NIOHTTPDecompression.DecompressionLimit = .ratio(10)) -> Self {
.init(isEnabled: true, limit: limit)
}
var isEnabled: Bool
var limit: NIOHTTPDecompression.DecompressionLimit
} That's how you could do it with a struct so we can add new cases going forward. |
Even more elegant would be to use a private enum inside the struct to model the different states. Eg public struct HTTPDecompressionConfiguration {
public static var disabled: Self {
.init(decompression: .disabled)
}
public static func enabled(limit: NIOHTTPDecompression.DecompressionLimit = .ratio(10)) -> Self {
.init(decompression: .enabled(limit: limit)
}
enum Decompression {
.disabled
.enabled(limit: NIOHTTPDecompression
}
var decompression: Decompression
} |
I've implemented an improved API here: #2214. |