Implement "permessage-deflate" extension for gateway #3944
-
There is RFC 7692 which describes concept "Compression Extensions" for WebSocket. RFC 7692 supported by major browsers since at least 2014 and isn't a draft anymore since 2016. PMCE supported by variety of libraries with WebSocket client implementations: Python, Node, .NET and .NET 6 (not yet), C++ (see protocol support), etc. At the same time Discord uses custom "zlib-stream" compression (apparently for both regular clients and bots) which isn't defined by widespread standards and requires to be manually implemented in order to work. However, "zlib-stream" is essentially representing the exact same stream compression that you will get by using These 2 bytes contain zlib header which consists of
That's what used by standard DEFLATE implementations. No difference there either so it seems that server implementation uses most standard parameters for zlib and could either trim header or just use deflate as is. So, in order to simplify compression support for clients, it is suggested to use widely-available standards instead of custom-made solution. It should remove needs to support custom compression handlers in client applications with little to zero intervention. Basically, in most cases bot developer could just remove their own code for transport compression and toggle an option in their WebSocket client. It also removes needs to include "compression" in get parameters to gateway since PMCE controlled by |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
Thanks for posting this. We don't have any current plans to support this extension. The two major points are: 1) we don't want to deal with inflate bombs from client->server compressed messages and 2) having our own non-standard compression scheme means we can update it to our requirements in the future, which we can't with permessage-deflate. One upside here is that thanks to how ubiquitous permessage-deflate is, there is lots of code you can use as a starting point to implement |
Beta Was this translation helpful? Give feedback.
Thanks for posting this. We don't have any current plans to support this extension. The two major points are: 1) we don't want to deal with inflate bombs from client->server compressed messages and 2) having our own non-standard compression scheme means we can update it to our requirements in the future, which we can't with permessage-deflate.
One upside here is that thanks to how ubiquitous permessage-deflate is, there is lots of code you can use as a starting point to implement
zlib-stream
.