permessage-deflate

[willrnch]

No description provided.

[spy16x]

What is the state of this implementation?

(I have built a websocket server for some production use-case with this lib. The clients are in flutter. Now I'm seeing a bunch of errors like ReservedBitsNotZero, InvalidValue while reading from the socket. My guess is, the client is doing compression 😅 I'm worried now that this doesn't have support yet).

[pboft]

What is the state of this implementation?

(I have built a websocket server for some production use-case with this lib. The clients are in flutter. Now I'm seeing a bunch of errors like ReservedBitsNotZero, InvalidValue while reading from the socket. My guess is, the client is doing compression 😅 I'm worried now that this doesn't have support yet).

I am seeing these too "ReservedBitsNotZero, InvalidValue while reading from the socket.". Originally, I believe it to be due to client-side deflate compression, however, strangely inspecting the raw packets in wireshark showed no set bits.

Regardless - what is required to help get this PR over the line ?

Also, is "ReservedBitsNotZero, InvalidValue while reading from the socket.". definitely not a parsing/decoding bug from the underlying library framing?

Thanks

[spy16x]

@pboft

The socket read/write are not cancellation safe. So if you're using them with tokio::select! or something it can cause partial frame reads and corrupt the whole stream.

This is what was happening in my case. Not related to compression.

I'd suggest you check this in your usecase too.

[pboft]

@pboft

The socket read/write are not cancellation safe. So if you're using them with tokio::select! or something it can cause partial frame reads and corrupt the whole stream.

This is what was happening in my case. Not related to compression.

I'd suggest you check this in your usecase too.

That's super helpful, sounds like it's exactly what might be happening. I'll check that out ASAP.

[willrnch]

What is the state of this implementation?

The current implementation support the most basic case and will inflate the message sent by the client if needed.
There is no protocol negotiation whatsoever so none of the extension parameters are supported (i.e. the server will not deflate any message, context takeover cannot be disabled and LZ77 sliding window size cannot be configured).

I'm working on protocol negotiation and will try to push soon.

[EvolveArt]

What is the state of this implementation?

The current implementation support the most basic case and will inflate the message sent by the client if needed. There is no protocol negotiation whatsoever so none of the extension parameters are supported (i.e. the server will not deflate any message, context takeover cannot be disabled and LZ77 sliding window size cannot be configured).

I'm working on protocol negotiation and will try to push soon.

hey @willrnch any update on this? happy to help

[algtm]

ping

[willrnch]

I've made some significant progress:

• Basic protocol negotiation
• Server frame compression
• Disable context takeover
• Configure LZ77 sliding window size
• Complex protocol negotiation (Need to handle more complex cases defined in the RFC: parameter selection)
• Support fragmented messages
• Fix frame header parsing
• Handle upgrade in IncomingUpgrade::upgrade and from_request_parts (not sure this is needed)
• Handle LZ77 sliding window size negotiation if the flate2 backend doesn't support it (via crate feature)
• autobahn test

[willrnch]

• Basic protocol negotiation
• Server frame compression
• Disable context takeover
• Configure LZ77 sliding window size
• Complex protocol negotiation (Need to handle more complex cases defined in the RFC: parameter selection)
• Support fragmented messages
• Fix frame header parsing
• Handle upgrade in IncomingUpgrade::upgrade and from_request_parts (not sure this is needed)
• Handle LZ77 sliding window size negotiation if the flate2 backend doesn't support it (via crate feature)
• autobahn test