gRPC Server doesn't respect grpc-accept-encoding header

[gigi]

Describe the bug

According to the gRPC specification:

For every message a server is requested to compress using an algorithm it knows the client doesn't support (as indicated by the last grpc-accept-encoding header received from the client), it SHALL send the message uncompressed.

Source: https://github.com/grpc/grpc/blob/master/doc/compression.md
Quarkus gRPC server does not respect the grpc-accept-encoding header sent by clients and instead relies solely on the quarkus.grpc.server.compression configuration setting when quarkus.grpc.server.use-separate-server=false.

Expected behavior

1. When quarkus.grpc.server.compression is empty → server responds with uncompressed messages
2. When quarkus.grpc.server.compression is set (e.g., "gzip") → server MUST read the client's grpc-accept-encoding header and:

• Compress the response ONLY if the client supports the compression algorithm (e.g., client sends grpc-accept-encoding: gzip)
• Send uncompressed response if client sends grpc-accept-encoding: identity
• Send uncompressed response if client doesn't list the server's compression algorithm

Actual behavior

Quarkus compresses or doesn't compress responses based solely on the quarkus.grpc.server.compression value, ignoring the grpc-accept-encoding header from the client.

How to Reproduce?

Added quick tests to illustrate the bug

Added two test cases for separate server and same http server:
https://github.com/gigi/quarkus-grpc-encoding-bug/blob/main/src/test/java/org/acme/

Output of uname -a or ver

Darwin 192.168.1.134 24.6.0 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041 arm64

Output of java -version

openjdk version "21.0.7" 2025-04-15 LTS OpenJDK Runtime Environment Temurin-21.0.7+6 (build 21.0.7+6-LTS) OpenJDK 64-Bit Server VM Temurin-21.0.7+6 (build 21.0.7+6-LTS, mixed mode, sharing)

Quarkus version or git rev

3.29.0

Build tool (ie. output of mvnw --version or gradlew --version)

------------------------------------------------------------ Gradle 8.9 ------------------------------------------------------------ Build time: 2024-07-11 14:37:41 UTC Revision: d536ef36a19186ccc596d8817123e5445f30fef8 Kotlin: 1.9.23 Groovy: 3.0.21 Ant: Apache Ant(TM) version 1.10.13 compiled on January 4 2023 Launcher JVM: 21.0.7 (Eclipse Adoptium 21.0.7+6-LTS) Daemon JVM: /Users/gigi/.sdkman/candidates/java/21.0.7-tem (no JDK specified, using current Java home) OS: Mac OS X 15.6.1 aarch64

Additional information

No response

[quarkus-bot]

/cc @alesj (grpc), @cescoffier (grpc), @geoand (kotlin)

[alesj]

@gigi I guess those helper methods (createHeaderInterceptor, createIdentityOnlyStub, createIdentityOnlyStub) are identical in both test classes?

[alesj]

Ah, and so are the tests ...
OK, let me have a closer look.

[gigi]

@alesj
Hi!
Emulating all possible scenarios was challenging because the built-in grpc client actively adds its own headers. Therefore, I used external low-level tools to debug the entire process.

[alesj]

I see this:

2025-11-03 13:25:56,554 INFO [io.qua.grp.run.sup.Channels] (main) gRPC client system-service created without configuration. We are assuming that it's created to test your gRPC services.

... but that's not the reason it fails ...

[alesj]

@gigi this looks suspicious:

• https://github.com/gigi/quarkus-grpc-encoding-bug/blob/main/src/test/java/org/acme/GrpcCompressionInterceptorIntegrationSeparateServerTest.java#L236

Can you check if other such similar usage is all OK ...

Imho, it should be createStubWithHeaderCapture, right?

[alesj]

Or this:

• https://github.com/gigi/quarkus-grpc-encoding-bug/blob/main/src/test/java/org/acme/GrpcCompressionInterceptorIntegrationSeparateServerTest.java#L119

It says "identity" should be advertised, but it's not.

[alesj]

gRPC's ClientCallImpl ...

  static void prepareHeaders(
      Metadata headers,
      DecompressorRegistry decompressorRegistry,
      Compressor compressor,
      boolean fullStreamDecompression) {
    headers.discardAll(CONTENT_LENGTH_KEY);
    headers.discardAll(MESSAGE_ENCODING_KEY);
    if (compressor != Codec.Identity.NONE) {
      headers.put(MESSAGE_ENCODING_KEY, compressor.getMessageEncoding());
    }

    headers.discardAll(MESSAGE_ACCEPT_ENCODING_KEY);
    byte[] advertisedEncodings =
        InternalDecompressorRegistry.getRawAdvertisedMessageEncodings(decompressorRegistry);
    if (advertisedEncodings.length != 0) {
      headers.put(MESSAGE_ACCEPT_ENCODING_KEY, advertisedEncodings);
    }

... it throws away user's encoding, only to apply what DecompressionRegistry supports / advertises ...

[alesj]

Hence this will never work ...

    @Test
    void shouldNotCompressWhenClientAcceptsMultipleEncodingsExceptGzip() {
        // Given: Client accepts multiple encodings but not gzip
        Metadata metadata = new Metadata();
        metadata.put(GRPC_ACCEPT_ENCODING_KEY, "identity,deflate,snappy");
        AtomicReference<String> responseEncoding = new AtomicReference<>();

        HelloGrpcGrpc.HelloGrpcBlockingStub stub = createStubWithHeaderCapture(metadata, responseEncoding);

unless we explicitly "adjust" DecompressRegistry in Quarkus gRPC client code - as it's done in createIdentityOnlyStub.

[gigi]

Quarkus gRPC server does not respect the grpc-accept-encoding header sent by clients and instead relies solely on the quarkus.grpc.server.compression configuration setting when quarkus.grpc.server.use-separate-server=false.

I think we can focus only on the tests related to the Vert.x server when quarkus.grpc.server.use-separate-server=false, and use GrpcCompressionInterceptorIntegrationTest.java
as a starting point to reproduce the bug.

We can skip GrpcCompressionInterceptorIntegrationSeparateServerTest.java, as it seems to work correctly. I spent a lot of time testing everything and left this class unchanged, but it appears irrelevant after three days of testing.

At this point, I can confirm that Quarkus always compresses the response if compression is enabled (quarkus.grpc.server.use-separate-server=false & quarkus.grpc.server.compression=gzip), regardless of what is advertised in the client’s request.

• no grpc-accept-encoding header
• grpc-accept-encoding: identity
• grpc-accept-encoding: identity,deflate

etc

The Quarkus client is not well-suited for testing such low-level behavior.

I used a custom Rust client to compose the grpc-accept-encoding header and Wireshark to check consistency between the grpc-encoding response header and the compression bit

[alesj]

OK, let me then use Vertx' gRPC components -- on server and client side.
Imho, the server has a few issues, where client will be better, as it assumes less then the gRPC Java one.