Received unsupported RSV flags 1

[nthouliss]

Hi,

I made a switch to Bandit with Phoenix (version 1.7.8) and got the following error on some of my websocket connections:

** (stop) {:deserializing, "Received unsupported RSV flags 1"}

I'm currently deployed on fly.io and my endpoint config isn't anything unusual.

  config :example_app, App.Endpoint,
    url: [host: host, port: 443, scheme: "https"],
    check_origin: [origin],
    http: [
      ip: {0, 0, 0, 0, 0, 0, 0, 0},
      port: port
    ],
    secret_key_base: secret_key_base

(I just changed the app name but that's the endpoint config).

The only thing that I could be doing differently than most set-ups is having my own serialiser on my websocket. I use message pack on my websocket messages so I need to use a customer serialiser.

This is likely a configuration issue rather than a bug in the library but I'm reporting since I'm not really sure where to start in fixing it.

Thanks, happy to provide any additional details.

[ryanwinchester]

Just a few questions for clarity:

I made a switch to Bandit with Phoenix (version 1.7.8)

1. You upgraded Phoenix and switched to Bandit at the same time?
2. Which version of Phoenix were you using previously?
3. It was deployed to fly.io, and working (with Cowboy and earlier Phoenix)?
4. Can you reproduce the error when running locally (on your machine)?

[nthouliss]

You upgraded Phoenix and switched to Bandit at the same time?

Yes, I upgraded at the same time. I've since rolled back the Bandit adapter and am running Phoenix 1.7.8 in fly.io with Cowboy without this issue. I've also updated my Elixir (now 1.14.5) and OTP (now 25.3.2.5) version.

Which version of Phoenix were you using previously?

I was using version 1.6.10 with Elixir 1.13.4 and OTP 25.0.2

It was deployed to fly.io, and working (with Cowboy and earlier Phoenix)?

Yes, it was deployed and working before the change. I also tested it on a stage environment in fly.io beforehand (with Bandit) and didn't run into this issue. For some reason and only for some connections, this error occurs.

Can you reproduce the error when running locally (on your machine)?

I haven't been able to reproduce this issue locally.

[ryanwinchester]

Looking a bit more, I suspect it's related to this:

https://www.rfc-editor.org/rfc/rfc6455#section-5.2

Getting a 1 instead of a 0 so it's failing (as it should?)...

I haven't looked deeper yet, though.

[moogle19]

This is odd.

The suspicion of @ryanwinchester seems correct. But Cowboy should also return an error in that case (see here).

@nthouliss Which client do you use for your websocket connections? And do you use permessage-deflate?

[nthouliss]

Yeah, I understand it would be the protocol responding as it should but I'm not sure why when I don't get this with Cowboy.

I don't have permessage-deflate enabled. I'm using the phoenix javascript library (version 1.7.7). I don't have any additional header configurations on fly.io either.

[mtrudel]

My first guess would be that the client here is trying to negotiate an extension that's provides meaning to the RSV flag (as @ryanwinchester correctly hunches). This shouldn't be the case (we're pretty iron clad about only accepting deflate), but you never know. Maybe we have a bug with negotiation if compress is disabled? It could be a lot of things; mostly just spitballing here.

Some data that would greatly help:

1. Do you know what the client(s) are that are causing this? Is it all clients or just a specific browser / other client?
2. Is it possible for you to get a handle on the sec-websocket-extensions header that's being sent when this occurs? You should be able to get this by injecting a plug at the very top of your endpoint.ex which can inspect and log as appropriate; this will catch websocket upgrade requests before they pass through the upgrade process.

[mtrudel]

Any feedback on the above @nthouliss ?

[nthouliss]

@mtrudel sorry I've been busy with some other things on my end.

I don't know what clients could be causing this specifically, it's not every connection. I'll make an adjustment to the endpoint to see what could cause it. It may take me a little, but I'll get back here with the info when I can :)

[mtrudel]

I'm going to go ahead and close this due to inactivity. If you get around to getting repro data (no worries if not!), feel free to reopen the issue.