Handling permessage-deflate requests

[zzgab]

Hello!
Is there a way to handle requests specifying compression header?
Sec-WebSocket-Extensions: permessage-deflate

Response should contain the same header (easy), but the request data ($msg in onMessage) would have to be inflated, so would the response data passed to send( ).

Advice appreciated!
Thanks,
Gabriel

[zzgab]

In fact, it would help to have some Extenstions mechanism. Sec-WebSocket-Extensions header can have several values, and by definition it is supposed to be extensible.

I could force the response header

$response->setHeader('Sec-WebSocket-Extensions', 'permessage-deflate');

in https://github.com/ratchetphp/Ratchet/blob/master/src/Ratchet/WebSocket/WsServer.php#L125

and then the client (browser) sends deflated data, but then RFC6455.php is unable to handle it.

But then I found that if I bypass the check on $frame->getRsv1(), getRsv2() and getRsv3() in https://github.com/ratchetphp/Ratchet/blob/master/src%2FRatchet%2FWebSocket%2FVersion%2FRFC6455.php#L121 , and also of course bypass the UTF8 check in https://github.com/ratchetphp/Ratchet/blob/master/src%2FRatchet%2FWebSocket%2FVersion%2FRFC6455.php#L199 then the compressed data makes it through my applicative onMessage handler.

In turn, my onMessage handler must inflate the compressed data, but I found that it is not enough to gzinflate it: the header is a bit different (must OR the very first byte of the stream with 0x01 in order to obtain valid input for gzinflate).

I wish someone could help be in this direction so as to stabilize, and possibly propose a proper Extensions system for future protocol features.

Thanks.

[cboden]

For 0.4 we're refactoring the protocol handler into its own repo. This is leading to a more loosely coupled protocol handler so doing things like handling extensions should become easier. You're on the right path with finding the header and message frames. Checked out the psr7 RFC branch to see where we're going and feel free to help contribute!

[zzgab]

Thanks!
About where in the https://github.com/ratchetphp/RFC6455/blob/psr7/README.md roadmad, do we stand currently?

[cboden]

v0.2 is almost done. We've actually already incorporated some performance enhancements in it as well (scheduled for v0.3). While extensions were slated for v0.4 if someone was willing to work on that feature I'd be happy to add it to the next release.

[edhelas]

Hi, do you thing that it's possible to integrate the permessage-deflate work done in Ratchet soon? I'm curious to know how this is going :)
Thanks again for the awesome work !

[cboden]

I just spoke with @mbonneau. We're going to start outlining a roadmap to include this. We've looked at it a couple times and have always hit a road block with the API. We're going to start documenting this process more openly and make a decision to move forward.

[PaulRotmann]

Hey! Thanks for reporting this issue 🙏

We're giving Ratchet some much-needed love and attention! As part of our issue cleanup initiative (#1100), we're reviewing our backlog and organizing features for upcoming releases.

Per-message-deflate compression is indeed something we want to implement! The underlying feature appears to already be built into our RFC project, but we still need to add the configuration options to make it user-friendly. We're not yet sure if this will make it into v0.4.5 or a later release.

We'll keep this issue open to track the implementation progress.

If you want to support Ratchet, please consider sponsoring our work! ❤️