Is there an existing issue for this?
OS/Web Information
- Web Browser: N/A
- Local OS: N/A
- Remote OS: Rocky 8
- Remote Architecture: x86_64
code-server --version: 4.4.0 b088ec7 with Code 1.66.2
Steps to Reproduce
Working:
curl -v 'http://acn01.agate.msi.umn.edu:46233/?type=Management&reconnectionToken=8d0dc359-d9c0-42bc-92d6-c5e0f8a4f52d&reconnection=false&skipWebSocketFrames=false' -H 'Connection: keep-alive, Upgrade' -H 'Cookie: code-server-session=REMOVED;' -H 'Upgrade: websocket'
Not working:
curl -v 'http://acn01.agate.msi.umn.edu:46233/?type=Management&reconnectionToken=8d0dc359-d9c0-42bc-92d6-c5e0f8a4f52d&reconnection=false&skipWebSocketFrames=false' -H 'Connection: keep-alive, Upgrade' -H 'Cookie: code-server-session=REMOVED;' -H 'Upgrade: WebSocket'
Only difference is the capitalization of the Upgrade header value.
Expected
Should get a HTTP/1.1 101 Switching Protocols response:
* Trying 10.31.104.175...
* TCP_NODELAY set
* Connected to acn01.agate.msi.umn.edu (10.31.104.175) port 46233 (#0)
> GET /?type=Management&reconnectionToken=8d0dc359-d9c0-42bc-92d6-c5e0f8a4f52d&reconnection=false&skipWebSocketFrames=false HTTP/1.1
> Host: acn01.agate.msi.umn.edu:46233
> User-Agent: curl/7.61.1
> Accept: */*
> Connection: keep-alive, Upgrade
> Cookie: code-server-session=REMOVED;
> Upgrade: websocket
>
< HTTP/1.1 101 Switching Protocols
< Upgrade: websocket
< Connection: Upgrade
< Sec-WebSocket-Accept: gH2cR3x4MfGXKljgIwL3fMYv0sY=
<
Actual
* Trying 10.31.104.175...
* TCP_NODELAY set
* Connected to acn01.agate.msi.umn.edu (10.31.104.175) port 46233 (#0)
> GET /?type=Management&reconnectionToken=8d0dc359-d9c0-42bc-92d6-c5e0f8a4f52d&reconnection=false&skipWebSocketFrames=false HTTP/1.1
> Host: acn01.agate.msi.umn.edu:46233
> User-Agent: curl/7.61.1
> Accept: */*
> Connection: keep-alive, Upgrade
> Cookie: code-server-session=REMOVED;
> Upgrade: WebSocket
>
* Empty reply from server
* Connection #0 to host acn01.agate.msi.umn.edu left intact
Additional variants such as webSocket and Websocket have the same result.
Logs
I couldn't find any logs related to these events even with --log trace enabled.
Screenshot/Video
No response
Does this issue happen in VS Code or GitHub Codespaces?
Are you accessing code-server over HTTPS?
Notes
I am attempting to have code-server sessions launched by our Open OnDemand instance, which uses Apache's mod_lua and mod_proxy_wstunnel to forward connections to jobs running on cluster compute nodes. I'm running into the same issue as others who have setup a proxy front-end to like #4723, but unfortunately the same solution cannot easily be applied in my case because of the dynamic nature of the proxy (configured through mod_lua). Also, I think #5110 might be related, but I'm not sure what CloudFlare's Upgrade string looks like as I don't use it.
mod_proxy_wstunnel is using a hard-coded Camel Case for WebSocket and is replacing the Upgrade: websocket that is received on the frontend from regular browsers. Per the RFC, the Upgrade option should be case insensitive, so this shouldn't matter.
I've checked both the ws and http-proxy npm modules to see if I could find the case sensitive comparison, but I wasn't able to track it down.
I have a temporary fix in place where I've edited the mod_proxy_wstunnel binary so that it sends a lowercase Upgrade: websocket and that has fixed the problem for now, but I'd appreciate if you were able to help me fix it so that code-server could use a case-insensitive Upgrade string.
Is there an existing issue for this?
OS/Web Information
code-server --version: 4.4.0 b088ec7 with Code 1.66.2Steps to Reproduce
Working:
Not working:
Only difference is the capitalization of the Upgrade header value.
Expected
Should get a
HTTP/1.1 101 Switching Protocolsresponse:Actual
Additional variants such as
webSocketandWebsockethave the same result.Logs
I couldn't find any logs related to these events even with
--log traceenabled.Screenshot/Video
No response
Does this issue happen in VS Code or GitHub Codespaces?
Are you accessing code-server over HTTPS?
Notes
I am attempting to have code-server sessions launched by our Open OnDemand instance, which uses Apache's mod_lua and mod_proxy_wstunnel to forward connections to jobs running on cluster compute nodes. I'm running into the same issue as others who have setup a proxy front-end to like #4723, but unfortunately the same solution cannot easily be applied in my case because of the dynamic nature of the proxy (configured through mod_lua). Also, I think #5110 might be related, but I'm not sure what CloudFlare's
Upgradestring looks like as I don't use it.mod_proxy_wstunnel is using a hard-coded Camel Case for WebSocket and is replacing the
Upgrade: websocketthat is received on the frontend from regular browsers. Per the RFC, theUpgradeoption should be case insensitive, so this shouldn't matter.I've checked both the
wsandhttp-proxynpm modules to see if I could find the case sensitive comparison, but I wasn't able to track it down.I have a temporary fix in place where I've edited the mod_proxy_wstunnel binary so that it sends a lowercase
Upgrade: websocketand that has fixed the problem for now, but I'd appreciate if you were able to help me fix it so that code-server could use a case-insensitiveUpgradestring.