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.