Documentation insondistency concerning websocket notifications

[sheerun]

https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications

It says "Note: The reason for this workaround is the lack of support for WebSockets from Rocket (though it's a planned feature), which forces us to launch a secondary server on a separate port."

I think it is not up do date because "it's a planned feature" links to rwf2/Rocket#90 which is closed

[BobWs]

This was added to the wiki a long time ago...

[JeDaYoshi]

It also doesn't mention that WebSocket support was directly added to the Rocket server.
However, it's currently only on beta, not on a stable release - although seems to be working well for me.

[ShlomiD83]

Hi all,
If I use WS on port 80 my chrome extension doesn't seem to update automatically.
If I use port 3012 everything works.

What am I doing wrong?

[quexten]

Are you using the latest beta release? On stable rocket notifications are not merged yet. Also you most likely need to change your reverse proxy configuration. (The documentation does not yet contain new tested configs for all proxies).

[tessus]

see also #3598
I guess it will get more info on the correct reverse proxy settings for the different reverse proxies over time

[ShlomiD83]

I'm using the latest beta release but my proxy config is a little different because of Authelia.
I'll have to mess with it to get WS to work.

[lusky3]

The current documentation on websockets after 1.29.0 is a bit of a mess. The instructions say to set it all up on 3012, with a docker example exposing 3012, then after all that it says in a small note that 3012 is no longer needed. On the reverse proxies example page, it states right off the bat that 3012 is needed (and Default).

Is this just a matter of updating all documentation to remove reference to 3012?

It's no longer entirely clear what needs to be done as the documentation suggestions using WEBSOCKET_ENABLED=true will still default to port 3012 in 1.29.0+, and just says it "supports" port 80. Is 80 not the default in 1.29.0? Is there any additional configuration needed for reverse proxies? And if websockets just work 'out-of-the-box' on the same port, is it not enabled by default? This apache comment seems to suggest the opposite of all the documentation and disable websockets in order to use it.

Any clarity would be greatly appreciated.

[quexten]

On the reverse proxies example page, it states right off the bat that 3012 is needed (and Default).

They are outdated. But there are also no new reverse proxy samples. Some require extra configuration some support websockets out of the box (traefik f.e). As long as your proxy supports websockets out of the box, you can disable port 3012 and leave out WEBSOCKET_ENABLED and remove any related proxy rules. With others you might require other (different from the examples) configuration to get websockets working over rocket.

And if websockets just work 'out-of-the-box' on the same port, is it not enabled by default?

The flag is outdated and websockets (over rocket) work without the WEBSOCKET_ENABLED flag and are enabled by default. It is just still there for backward compatibility of old server installations.

[BlackDex]

@lusky3 i think that all is kinda explained very well in #3598, but indeed the WebSocket wiki page was not updated.
I have done that just right now, and it should be more clear now I think.

If not, you are free to adjust it 😉 .

[tessus]

@lusky3 here is a bit of history, otherwise you might not fully understand why it is as it is:

At first, rocket (the web framework vw uses) was not able to run http and websocket traffic on the same port. So the vw devs just added another port for using an exclusive websocket connection. This socket was activated by setting WEBSOCKET_ENABLED to true.
All the proxy examples on the wiki (as of 2023-07-19) describe how to reverse proxy http on port ROCKET_PORT and websockets on port 3012.

Year 2023: rocket gains the capablity of running websockets on the same port as http. The vw devs also implement this new capability for vw. Now websockets run on port ROCKET_PORT.
But the "old" code is still there. So in the current state, websockets run on port ROCKET_PORT and also on port 3012 if you have WEBSOCKET_ENABLED set to true (remember, this option started websockets on a separate port). So your previous reverse proxy config still works. Nothing has changed so far.

However, why would you want to run an additional websockets port, if it was no longer necessary? This is why and where the new reverse proxy settings come in. So first you want to deactivate the websocket connection on port 3012: WEBSOCKET_ENABLED=false. (Setting this to false does not mean that there is no websockets support. It only turns off the separate port for websockets.) And of course after that it makes no sense to reverse proxy websocket connections to a port that is no longer available. So you only have to change the port info in your reverse proxy config from 3012 to ROCKET_PORT.

Additionally to all that, Apache httpd got a new feature in version 2.4.47, which no longer requires Rewrite options and rules for reverse proxying websockets. This is the reason why from version 2.4.47 onwards, the config can be simplified to only one line.

Here ends the history lesson. ;-)

[lusky3]

Thank you all for the clarity and edits.

I figured it was just the documentation lagging behind the release, and was considering editing it, but I didn't want to assume.

Part of my confusion was the flag "WEBSOCKET_ENABLED=false" which doesn't actually enable/disable websocket support, it just starts an additional listener on port ROCKET_PORT={$ROCKET_PORT:-3012} for a time when both protocols could not coexist on the same port.

Just that added note on the websockets wiki page provided the picture.

The old WEBSOCKET_ENABLED and WEBSOCKET_PORT are not needed anymore since v1.29.0 of Vaultwarden and can be ignored.

[BlackDex]

Part of my confusion was the flag "WEBSOCKET_ENABLED=false" which doesn't actually enable/disable websocket support, it just starts an additional listener on port ROCKET_PORT={$ROCKET_PORT:-3012} for a time when both protocols could not coexist on the same port.

Well that isn't true. It doesn't start an other listener on the ROCKER_PORT, since Rocket wasn't able to be handle it.

It actually starts a whole separate thread running thungstintie as a server to handle the requests. Messages are exchanged via MPSC between the threads.

[lusky3]

I guess my terminology is wrong. I was referring to any service listening on a port to be a listener. In this case, thungstintie is the listener that is started.