RFC 008: Server compression preference

astro.config.mjs

@@ -162,6 +162,10 @@ export default defineConfig({
                   label: "007: Rust Implementation",
                   slug: "docs/governance/rfc/007-rust-implementation",
                 },
+                {
+                  label: "008: Server compression preference",
+                  slug: "docs/governance/rfc/008-server-compression-preference",
+                },
               ],
             },
           ],

src/content/docs/docs/governance/rfc/008-server-compression-preference.md

@@ -0,0 +1,54 @@
+---
+title: "008: Server compression preference"
+---
+
+This RFC proposes amending the Connect protocol to have servers define the
+preference for a compression algorithm among the supported set as opposed to
+the client. This allows improving compression in scenarios where the client's
+ordering cannot be changed, like the browser, and aligns with the commonly
+accepted behavior of servers like Envoy and NGINX.
+
+The proposed diff to the protocol specification is in [PR 322][pr322]. This
+document focuses on the rationale for the change and the anticipated end user
+impact.
+
+## Current behavior
+
+The compression algorithm to use for a response is determined by two factors:
+
+- The list of supported compression methods configured on the server
+- The list of supported compression methods in the client's `Accept-Encoding` header, e.g., `gzip, br, zstd`
+
+Currently, it is the order in the `Accept-Encoding` header that determines which
+algorithm to prefer. The server chooses the first compression method that it supports.
+
+Because common browsers always send `gzip, deflate, br, zstd`, and because all current Connect server implementations support `gzip` by default, it is currently impossible for
+connect-web users to use the more modern and efficient `br` and `zstd` algorithms unless a Connect server disables support for `gzip`.
+
+## Proposed behavior
+
+We propose changing the algorithm so that servers are configured with an ordered list of compression methods.
+and the first matching method present in the `Accept-Encoding` header is selected if the client has not compressed
+the request.
+
+For example, given this header from a client: `Accept-Encoding: gzip, br, zstd`
+
+- If the server's list of supported compression methods is `[gzip, br, zstd]`, then the server selects `gzip` as the compression method.
+- If the server's list of supported compression methods is `[br, zstd, gzip]`, then the server selects `br` as the compression method.
+
+If the request is compressed, including a `Content-Encoding` header with a valid compression algorithm, that algorithm must be
+used without consulting `Accept-Encoding`.
+
+The above matching should be used for all RPCs, including unary and streaming, and non-Connect protocol RPCs. The header names
+may be different but should otherwise select a compression in the same way.
+
+Moving preference to the server will allow preferring the more efficient algorithms, finally
+unlocking them for connect-web. Servers like Envoy and NGINX behave in the same way for the
+same reason.
+
+While `br` and `zstd` have come a long way and commonly have similar CPU and RAM usage to
+`gzip` now, it can't be confirmed all workloads will see no regression from a change from
+`gzip` to e.g., `br`. In an abundance of caution, if this RFC is approved, then this new behavior will only be introduced in Connect implementations as part of a major version. It is planned to be introduced to Connect-Go in v2, Connect-Py before v1, and Connect-ES
+in v3.
+
+[pr322]: https://github.com/connectrpc/connectrpc.com/pull/322