feat(codec): Add ServerCompressionInterceptor for gRPC compression - #2649
Open
sauravzg wants to merge 2 commits into
Open
feat(codec): Add ServerCompressionInterceptor for gRPC compression#2649sauravzg wants to merge 2 commits into
sauravzg wants to merge 2 commits into
Conversation
sauravzg
force-pushed
the
sauravz/server-compression
branch
2 times, most recently
from
May 19, 2026 14:26
beb2595 to
5acb682
Compare
sauravzg
force-pushed
the
sauravz/server-compression
branch
from
May 22, 2026 11:13
5acb682 to
b4af9e3
Compare
sauravzg
force-pushed
the
sauravz/server-compression
branch
from
May 22, 2026 11:39
b4af9e3 to
bcfd493
Compare
Member
|
@saurav - this PR is not targetting master. Is that intentional? |
Contributor
Author
Yes. I am trying out a stacked PR approach, every PR is targetting its parent PR. |
Member
So then.... we end up with a branch that has all the changes on it that we want, and then we create a final PR that merges that branch to master once it's all done? |
Contributor
Author
|
I plan to rely on https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#working-with-branches to retarget branch to head when the parent PR gets merged. So, I am supposed to merge the parent PR first i.e. #2648 . After which , github will auto target this PR to master. So, the the features missing from https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches#working-with-branches , are
I don't care about 1 right now and plan to manually handle 2 myself. |
sauravzg
force-pushed
the
sauravz/server-compression
branch
from
July 14, 2026 15:29
bcfd493 to
5fac1c7
Compare
sauravzg
force-pushed
the
sauravz/server-compression
branch
from
July 15, 2026 17:35
5fac1c7 to
480516d
Compare
…istry This change introduces the foundational compression abstractions and implementations for the grpc server component. - **Compression API (`grpc/src/codec/compression.rs`)**: Defines the `Compressor` and `Decompressor` traits for handling the compression and decompression of gRPC payloads via byte buffers. - **Simplified Design Philosophy**: The API is intentionally kept simple. It deliberately avoids handling concerns like limiting input and output buffer sizes, instead delegating these safety boundaries to the higher-level gRPC business logic. - **Performance Improvements**: By relying on direct buffer manipulation, this implementation avoids the hidden memory copying overhead present in the `tonic` crate (which utilizes 8KB intermediate buffers for I/O). - **Standard Algorithms**: Implements `gzip`, `deflate`, and `zstd` compression logic in their respective modules. These are conditionally compiled based on feature flags. - **Global Registry (`registry.rs`)**: Introduces a thread-safe `GlobalCompressionRegistry` (backed by `RwLock` and `Arc`) to manage registered compressors and decompressors. It handles safe concurrent access and automatically updates the broadcasted `grpc-accept-encoding` headers. - **Module Integration**: Exposes the new `codec` and `compression` modules to the library's root structure.
⚠️ TRADEOFFS & LIMITATIONS⚠️ Due to the current limitations of the `RecvStream` API (which lacks out-of-band compression signals), this implementation introduces a high degree of coupling between the HTTP transport, compression, and serialization layers. Consequently, this design necessitates type erasure(IncomingRawMessage) and incurs a forced `Box` allocation penalty to function within the existing stream boundaries. This change introduces the `ServerCompressionInterceptor`, which integrates compression and decompression capabilities into the server-side gRPC request/response lifecycle. Key additions: - **`ServerCompressionInterceptor`**: Implements the `Intercept` trait to wrap incoming requests. It parses the `grpc-encoding` and `grpc-accept-encoding` headers to determine the appropriate `Compressor` and `Decompressor` to use. - **Decompression Bomb Mitigation**: Protects against decompression bomb (zip bomb) attacks by strictly limiting writes during the decompression process. - **`CompressionResolver` Integration**: Uses a `CompressionResolver` registry to look up algorithms by name. - **Stream Wrapping**: Wraps the underlying `RecvStream` (to decompress incoming messages) and `SendStream` (to compress outgoing messages and inject the correct `grpc-encoding` header). - **Error Handling**: Returns standard gRPC status errors if an encoding is unsupported or if compression/decompression fails during stream processing. - **Unit Tests**: Includes a comprehensive suite of Tokio-based tests covering successful compression/decompression, unsupported encoding errors, registry lookup failures, and fallback mechanisms.
sauravzg
force-pushed
the
sauravz/server-compression
branch
from
July 15, 2026 18:02
480516d to
0f77d89
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
RecvStreamAPI (which lacks out-of-band compression signals), this implementation introduces a high degree of coupling between the HTTP transport, compression, and serialization layers. Consequently, this design necessitates type erasure(IncomingRawMessage) and incurs a forcedBoxallocation penalty to function within the existing stream boundaries.This change introduces the
ServerCompressionInterceptor, which integrates compression and decompression capabilities into the server-side gRPC request/response lifecycle.Key additions:
ServerCompressionInterceptor: Implements theIntercepttrait to wrap incoming requests. It parses thegrpc-encodingandgrpc-accept-encodingheaders to determine the appropriateCompressorandDecompressorto use.CompressionResolverIntegration: Uses aCompressionResolverregistry to look up algorithms by name.RecvStream(to decompress incoming messages) andSendStream(to compress outgoing messages and inject the correctgrpc-encodingheader).