-
Notifications
You must be signed in to change notification settings - Fork 82
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
Gzip compression level 0 #313
Comments
I think that you can use The problem though is that we clamp it based on min/max supported by flate2 https://docs.rs/async-compression/latest/src/async_compression/lib.rs.html#216 And flate2 fastest uses compression level 1 https://docs.rs/flate2/latest/src/flate2/lib.rs.html#218-220 |
If I understand correctly, the The use case is that we have some test cases that explicitly disable compression, such as https://github.com/rust-lang/crates.io/blob/000197227fb963d91612d2bcdf360bea44b7bd34/src/tests/krate/publish/max_size.rs#L40:L41. However, while I tried to implement this using |
Yes and that is because I believe it's better to update flate2 to use level 0? |
Yeah, it would be great the Self::Precise(quality) => flate2::Compression::new(
quality
.try_into()
.unwrap_or(0)
.clamp(flate2::Compression::none(), best.level()),
), |
Hmmm I think this makes sense to make. I would accept a PR for this. |
Currently, the compression level for Gzip is clamped between 1 (fast) and 9 (best). However, level 0 is supported by the flate2 crate and Python's gzip module. While changing the level range could be a breaking change, are there any alternative approaches to address this issue? For example, introducing a
none
level might be a viable solution?The text was updated successfully, but these errors were encountered: