[permessage-deflate] Failed to perform decompression: -2

[mitchhentges]

Encountered an error: WebSocket Protocol Error: Failed to perform decompression: -2
Enable a logger to see more information.

And I have no idea how to enable a logger! 😢

---

I've set up a server with ssl and permessage-deflate. This is working excellently in "production": proxied through nginx and set up with a DNS record + SSL certificate.

However, when developing locally, sending messages to the server cause it to fail decompression, and print the above error. (Note: even if I don't use the ssl feature, just using permessage-deflate causes the same issue)

---

To reproduce

1. Clone https://gitlab.com/fuzz-chat/server, commit 4147d152819a0f9de4c93b6b7e45b28f1033dad1
2. cargo run
3. In Chrome:

var ws = new WebSocket('ws://localhost:9015?name=Mitch')

then

ws.send(JSON.stringify({
	_type: "SEND_MESSAGE",
	content: "4real though, this ws-rs library is awesome, and the docs are super legit!",
	date: new Date()
}))

[housleyjk]

This happened on my box just recently. It's possible that there is a linking problem with pkg-config. Or there could be changes in libz since version 1.2.8 that libz-sys and WS-RS expect that lead to this issue, I don't know. Anyway, the fix for me was to set the LIBZ_SYS_STATIC=1 environment variable see the libz-sys build script before compiling libz-sys.

I'm sorry this took so long, but this was a real pain to figure out. Let me know if that works for you.

[housleyjk]

Oh and for setting up a logger, see most of the examples, like client.

[mitchhentges]

First, when attaching env_logger, without setting LIBZ_SYS_STATIC=1:

2017-02-18 20:09:28.565283333 UTC [Mitch connected]
ERROR:ws::handler: WS Error <Protocol>: Failed to perform decompression: -2
2017-02-18 20:09:29.630413341 UTC [Mitch disconnected]
ERROR:ws::deflate::context: Compression stream encountered bad state.
ERROR:ws::deflate::context: Decompression stream encountered bad state.

So, I know that the streams encounter a bad state, which I suppose might be useful.

---

When I set LIBZ_SYS_STATIC=1 and did a clean build, my problem was solved. Is there a way that I can have that environment variable automatically set when I run my build? I found Pass environment variables to dependencies and Allow reexporting of features between packages, but I'm not sure how to use the new re-exporting feature to solve this problem.

What I'd like is for people to be able to clone my project and do cargo run, and it works out-of-the-box. I'd rather not require them to set LIBZ_SYS_STATIC themselves, or have to maintain bash/windows build scripts

[housleyjk]

I understand, but I haven't figured that one out yet myself. I would like to avoid needing to set an environment variable too. What type of system are you using? I'm on Arch Linux, and I've only seen this issue on my personal box. I'm wondering if this is really a libz-sys issue that has to be fixed from there. I'm thinking it's essentially a bug in that build script. Alternatively, perhaps we can add a script to WS-RS that sets the environment variable so that when WS-RS is built and libz-sys is built as a dependency, it will just work, but I do think this is something that should be fixed in libz-sys if possible.

[mitchhentges]

My personal box is also Arch Linux.
Interestingly, my server (which is also Arch Linux), is also failing just as consistently as my my personal machine. I update it less frequently, so perhaps some update borked it between sometime before January 18 (when I reported the issue) and now, when it is also having the same "Websocket Protocol Error".

TL;DR, I'm running Arch Linux too, neat!

[mitchhentges]

This seems to be working for me, I'll reopen/investigate further if I run into this again

[rocallahan]

I'm hitting this in ws 0.7.3.

[rocallahan]

deflate is failing in deflateStateCheck. The problem is that strm->s->state != strm. My guess is that the z_stream is being moved. You have the z_stream as a direct member of Compresser, and there's no way to stop Rust moving the Compresser value between stream init and use, and any such movement will trigger this failure.

[rocallahan]

In my case the move occurs at entry.insert(Connection::new(tok, sock, handler, settings, connection_id)); in io.rs.

[rocallahan]

This is a debug build; it may be with with optimizations enabled the bug goes away.

[rocallahan]

I'll submit a PR.