mkurz commented on code in PR #1114:
URL: https://github.com/apache/pekko-http/pull/1114#discussion_r3504453939
##########
http-core/src/main/resources/reference.conf:
##########
@@ -348,6 +348,44 @@ pekko.http {
# Enable verbose debug logging for all ingoing and outgoing frames
log-frames = false
+
+ compression {
+ # Whether the server should support WebSocket compression using the
RFC 7692
+ # permessage-deflate extension. Compression is negotiated during the
+ # WebSocket handshake and is only used when the client requests it.
+ enabled = true
Review Comment:
Could you clarify what kind of adaptive compression you mean?
With this PR, Pekko HTTP already supports adaptation in two ways:
1. Compression is only negotiated when the client offers
`permessage-deflate`.
2. Compression can be disabled globally, or per accepted WebSocket via the
new `compressionEnabled` overloads.
If you mean **adapting per outbound message**, for example compressing a
large message but sending a small message uncompressed, I think that could make
sense as a follow-up PR. `permessage-deflate` allows this: once the extension
is negotiated, a sender can still choose to leave RSV1 unset for individual
messages. This would need careful handling around fragmented messages and
context takeover, but a minimum-size threshold or application-controlled filter
could be useful.
In Play we do basically the same for the gzip filter:
https://github.com/playframework/playframework/blob/d87116f880789e0dbc40b7f971e08638e5ab7557/web/play-filters-helpers/src/main/resources/reference.conf#L297-L300
- which avoids gziping content that is smaller then a certain threshold.
But, as said, I would do that in a follow up PR if desired.
Similarly, **skipping compression for certain message types or
already-compressed payloads** could make sense later, but Pekko HTTP currently
does not know application-level message semantics at this layer, so that would
also need separate design.
If you mean **changing the compression level dynamically**, that is more
complicated and probably less useful as a general automatic feature. A simpler
and more realistic variant would be allowing applications to choose a
**compression level per WebSocket connection**, similar to how this PR allows
enabling/disabling compression per accepted WebSocket. That should be much
easier to reason about than changing the level message-by-message.
I would also do that in a follow up PR if desired.
If you mean disabling compression automatically under CPU or memory
pressure, I think that is much larger in scope and probably not a good fit for
this PR. It would need metrics, policy, and predictable behavior, and I am not
sure the added complexity would be worth it.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
