rcthomas
commented
5 months ago I think I'm observing this with 4.1.1 and jupyterlab-nvdashboard, which uses bokeh:
[W 2024-03-13 06:19:15.107 SingleUserLabApp handlers:539] Websocket subprotocol between proxy/server (None)
became different than for client/proxy (bokeh) due to https://github.com/jupyterhub/jupyter-server-proxy/issues/459.
Requested subprotocols were ['bokeh'].This causes bokeh.protocol.exceptions.ProtocolError: Subprotocol header is not 'bokeh'
consideRatio
Looking at #442 led me to conclude that when a websocket connection is being proxied, we establish the client/proxy socket fully before establishing a proxy/server connection. This is a problem, because when a websocket is established, a client requests subprotocols it knows how to speak, and the server is to choose one it supports. The choice of subprotocol influences the format of the sent messages, so its critical that the server we proxy to gets to decide this. Currently though, we just pick the first subprotocol instead and hope that the server we proxy to will later accept it.
In #458 I added test cases to confirm our bugged behavior, and test cases we could switch to if we resolve this by not finalizing the client/proxy handshake before we establish a server/proxy handshake.
This bug is probably not very problematic, and with #458, I'm looking to provide a warning in case it could be a problem. The problem would arise mostly if the client doesn't know how to correctly interact with the server, so I think this can be left unresolved until there is a clear example of when this becomes relevant. The complexity to solve this bug could be notable.
Related