[PR] feat(runtime): Support deflate message compression [pekko-grpc]

["pjfanning (via GitHub)" <gi...@apache.org>]

pjfanning opened a new pull request, #926:
URL: https://github.com/apache/pekko-grpc/pull/926

   ### Motivation
   Pekko gRPC supported only the `gzip` and `identity` message encodings. A client that compresses requests with `deflate` (e.g. one built on gRPC C-core) got `UNIMPLEMENTED`.
   
   `Codecs.negotiate` only read the first `grpc-accept-encoding` header, so encodings listed in any later header were ignored.
   
   ### Modification
   - New `Deflate` codec for the gRPC `deflate` encoding, which is the zlib format (RFC 1950), not raw DEFLATE. It is built on `java.util.zip` `DeflaterOutputStream`/`InflaterInputStream` and added to `Codecs.supportedCodecs` (`gzip`, `deflate`, `identity`).
   - Gzip's size-bounded decompression loop moves into a new internal `StreamingZipCodec`, which `Gzip` and `Deflate` extend. Deflate therefore enforces `max-inbound-message-size` while it decompresses, so a deflate bomb is rejected with `RESOURCE_EXHAUSTED` without being inflated in full.
   - `Message-Accept-Encoding.findIn` returns the encodings of all `grpc-accept-encoding` headers, in the order they were sent. `Codecs.negotiate` picks the first supported one, so the client's order is respected:
     - `deflate, gzip` gives deflate.
     - `gzip, deflate` gives gzip.
     - `identity, deflate, gzip` (C-core's list) gives identity.
   - A new "Message compression" section in `server/details.md`.
   
   The pekko-http client backend uses `Codecs.supportedCodecs` too. It now advertises `gzip,deflate,identity` and can decode deflate responses. Its requests are still sent uncompressed; that is #923. The Netty backend is unchanged.
   
   ### Result
   The server accepts deflate-compressed requests, and sends deflate responses when deflate is the first supported encoding the client accepts.
   
   ### Tests
   - `CodecsSpec`: deflate negotiation and detection, the client's order within one header and across several headers
   - `MaxInboundMessageSizeSpec`: deflate bombs (streaming and strict decoders), the size limit, and the zlib format (header check, decodable by a plain `Inflater`)
   - New `DeflateCompressionSpec`: a deflate request through a generated handler, with a deflate or gzip response depending on the client's order
   - Directional: with `Deflate` left out of `supportedCodecs`, the negotiation, detection and end-to-end tests fail. With the old `findIn`, the multiple-headers test fails.
   - `sbt runtime/test`: 200 passed
   - `sbt interop-tests/test`: 256 passed
   - `sbt runtime/mimaReportBinaryIssues`: passed
   - `sbt headerCheckAll`, `sbt docs/paradox`: passed
   - `scalafmt --mode diff-ref=upstream/main` run
   
   ### References
   Fixes #924. Refs #923
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@pekko.apache.org
For additional commands, e-mail: notifications-help@pekko.apache.org