akka-http
akka-http copied to clipboard
akka
Support for WebSocket Extensions
Continuation of akka/akka#18709 We currently do not support websocket extensions (i.e. registering "an extension" in the server, or requesting one in the client).
Currently we see no strong need to provide this functionality. If you have a strong use case for it, please comment here
One example use case: web socket compression, current draft: https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-28
Nice overview here: https://www.igvita.com/2013/11/27/configuring-and-optimizing-websocket-compression/
Implementing this either requires a way to register such an extension or to implement it internally in Akka HTTP. I think that even if we would implement permessage ourselves it would be nice if it was done through an extension API rather than directly in the blueprints etc.
Note that the original ticket was closed because of lack of interest in it.
Final version of the standard seems to be RFC 7692
One reason it is not completely trivial to implement is that JDK Deflate doesn't support setting window sizes to limit the amount of memory a receiver needs to keep between decompressing chunks.
It's been difficult to track exactly what the state of the art is in Web Sockets compression support, but it seems like most of the major browsers send headers related to compression:
Sec-WebSocket-Extensions: permessage-deflate for Firefox and Chrome
Sec-WebSocket-Extensions: x-webkit-deflate-frame for Safari
It seems like it should be possible for Akka HTTP to take this into account and enable compression when requested.
The issue so far remains a low priority for us; if you'd like to give implementing this a shot, that would be very welcome though @acjay :-) Thanks in advance!
Compression is a use case for my team as well. We have a kind of request response pattern over the websocket and sometimes our responses are large around 1 to 4 MB.
Now we put up a manual compression over it and we observed that the data size becomes 7% of what it was and the time between such a request and its response becomes 35% of what it was.
Now, the problem with such a custom method is that debugging the websocket messages becomes a huge pain. I don't want to decompress every message for debugging some problem. For that reason we're not taking this to prod.
I believe compression itself is a strong enough reason to support it natively.
