I was surprised to see that the C++ core interprets "grpc-accept-encoding: deflate" like HTTP: it compresses messages using zlib with deflate compression, rather than using raw deflate. Matching HTTP semantics makes sense, of course, but this misnomer has historically confused HTTP implementations too.
This detail didn't seem important enough to warrant inclusion in the main protocol specification, so I've proposed an addition to `docs/compression.md` to document the expected behavior. I'm happy to move the addition around if you'd prefer it elsewhere.
Closes#36113
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36113 from akshayjshah:deflate 9177d39d63
PiperOrigin-RevId: 617635558
"initial call" should not be understood as "initial call on the connection" but
"initial call of the RPC". All the data necessary for understanding client's
compression abilities is provide per-RPC, so no connection-level state should
be used. Using such state would break the use of proxies.
Akshay Shah