Skip to content
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

feat: add auto_encoding and improve send_compressed behavior #2058

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

m62624
Copy link

@m62624 m62624 commented Nov 20, 2024


name: 💡 Feature Request
about: feat: Add auto_encoding and improve send_compressed behavior


Feature Request

Crates

tonic

Motivation

When using send_compressed, the server sends compressed data in a format that may not be explicitly allowed for the service, even if the format isn't listed as supported by the server. This means that the client receives the desired compression result, even if the server has not explicitly enabled that compression algorithm for the service.

The server should only send compressed data using algorithms that are supported by both the client and the server. If the client requests a compression format that the server does not support, the server should either send the data uncompressed (using identity) or return an error (Status).

Currently:

  • If send_compressed is set for the service, the from_accept_encoding_header method executes regardless of the provided grpc-accept-encoding.
  • The function responsible for selecting the compression algorithm on the server side does not respect the send_compression_encodings configuration.

This means that when processing a response, the server uses the grpc-accept-encoding header sent by the client and chooses the first supported compression algorithm, ignoring whether that algorithm is explicitly allowed in send_compression_encodings.

This results in unexpected behavior, as the server should only use compression types explicitly allowed via send_compressed.

Proposal

The logic has been refactored to address this issue:

  • If send_compressed is used and the server-client compression formats do not overlap, the server sends data without compression (identity).
  • An auto_encoding method has been added to automatically select the correct compression format based on the intersection of client and server-supported formats. That is, the server sends the desired format to each client.

This change ensures alignment with expected gRPC behavior.

Alternatives

  1. Retain the existing behavior but document the limitation.
    Drawback: It continues to cause unexpected issues when formats don't align.
  2. Return an error when formats do not match.
    Drawback: It might unnecessarily interrupt communication where uncompressed data could suffice.

New Test Suite:

Automatic Encoding Feature:

…vior

The service was initially configured to send compressed data only in Gzip format. Different clients requested varying compression algorithms (e.g., Gzip and Zstd).

Logs showed the following behavior:
1. Client 1 requested Gzip:
```
Server received request: data="gzip", headers=MetadataMap { headers: {"te": "trailers", "content-type": "application/grpc", "grpc-encoding": "gzip", "grpc-accept-encoding": "gzip,identity", "user-agent": "tonic/0.13.0"} } Server sending response: gzip Responding with gzip compression
```
2. Client 2 requested Zstd:
```
Server received request: data="zstd", headers=MetadataMap { headers: {"te": "trailers", "content-type": "application/grpc", "grpc-encoding": "gzip", "grpc-accept-encoding": "zstd,identity", "user-agent": "tonic/0.13.0"} }
```

It is clear that clients requested different encoders using `grpc-accept-encoding`.

**Expected behavior:**
- The server should select a compression algorithm from the intersection of the supported algorithms from the server and the client.
- If the client requests a compression algorithm not supported by the server, the server should either use `identity` (no compression) or return a `UNIMPLEMENTED` status.

**Actual behavior:**
If any `send_compressed` configuration was set for the service, the `from_accept_encoding_header` method was triggered regardless of the `grpc-accept-encoding` header provided by the client.
The function responsible for compression selection on the server did not respect `send_compression_encodings`.
The server defaulted to the first supported compression algorithm from `grpc-accept-encoding` without checking if the algorithm was allowed by `send_compression_encodings`.

**Resolution:**
- If `send_compressed` is not specified, the server defaults to `identity`.
- If `send_compressed` is specified, the server only compresses responses for clients explicitly requesting a supported algorithm.

**Feature:**
The `auto_encoding` mechanism was added. This allows the server to automatically
select a compression algorithm supported by the client without requiring explicit configuration of `send_compressed` on the server.
The server dynamically adjusts compression behavior, ensuring compatibility with client preferences for efficient communication.
@imotai
Copy link

imotai commented Nov 20, 2024

Did you use AI to generate the description? If so, could you please share it?

@m62624
Copy link
Author

m62624 commented Nov 20, 2024

Did you use AI to generate the description? If so, could you please share it?

Starting from the "New Test Suite:" section, I generated the content using GitHub Copilot directly on the PR submission page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants