Lighttpd

Which lighttpd version are you running?

Using MacOS lighttpd/1.4.72 (ssl) - a light and fast webserver

I also tried using netcat as a port 9000 receiver and got the same result.

Is there anything else in the logs?
What is the client that is connecting?
Did you try enabling other debug in lighttpd? Configuration: Debug Variables
Did you try looking at dtruss output from lighttpd? From your backend? Any errors before connection is closed?
Did you try temporarily disabling HTTP/2 in lighttpd? server.feature-flags
How did you build lighttpd? Or from where did you get the package?
What version of MacOS?

Running MacOS Ventura with lighttpd installed via brew.
Enabled all logging and disabled HTTP/2 (below). The client connecting is a react app using code below running in Chrome 17.0.5938.149. I note that with a IXWebSocket backend bypassing lighttpd, the binary option in the client works flawlessly. I want to use lighttpd though if possible.

import { w3cwebsocket } from 'websocket';
const  wsclient = new w3cwebsocket(`ws://${window.location.hostname}:8888/nlcsock`);
wsclient.binaryType = 'arraybuffer';
wsclient.onopen = () => {
   const byteArray = new Uint8Array(4);
   byteArray[0]=65;
   byteArray[1]=66;
   byteArray[2]=67;
   byteArray[3]=68;
   wsclient.send(byteArray);
};

2023-10-17 21:46:07: (gw_backend.c.1117) proc: tcp:127.0.0.1:9000 0 0 0 0
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: GET /nlcsock HTTP/1.1
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Host: localhost:8888
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Connection: Upgrade
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Pragma: no-cache
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Cache-Control: no-cache
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Upgrade: websocket
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Origin: http://localhost:3000
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Sec-WebSocket-Version: 13
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Accept-Encoding: gzip, deflate, br
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Accept-Language: en-US,en;q=0.9
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Cookie: nlc-login=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJubGMiLCJzdWIiOiJ3ZWJzb2NrZXQiLCJleHAiOjE2OTg3MjI3NDAsInVzZXJuYW1lIjoiYWRtaW4ifQ.me4v49UeFEOHkr_rTCqbzsbZv3b1qtc8-um3N5pxKKU
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Sec-WebSocket-Key: z33g3yKAr5spw4elmAwAiw==
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
2023-10-17 21:46:08: (h1.c.497) fd:8 rqst: 
2023-10-17 21:46:08: (configfile-glue.c.600) === start of condition block ===
2023-10-17 21:46:08: (configfile-glue.c.531) $HTTP["url"] =^ "/nlcsock" compare to /nlcsock
2023-10-17 21:46:08: (configfile-glue.c.388) 1 (uncached) result: true (cond: global / $HTTP["url"] =^ "/nlcsock")
2023-10-17 21:46:08: (response.c.295) -- parsed Request-URI
2023-10-17 21:46:08: (response.c.297) Request-URI     : /nlcsock
2023-10-17 21:46:08: (response.c.299) URI-scheme      : http
2023-10-17 21:46:08: (response.c.301) URI-authority   : localhost:8888
2023-10-17 21:46:08: (response.c.303) URI-path (clean): /nlcsock
2023-10-17 21:46:08: (response.c.305) URI-query       : 
2023-10-17 21:46:08: (gw_backend.c.981) gw - found a host 127.0.0.1 9000
2023-10-17 21:46:08: (gw_backend.c.2767) handling the request using wstunnel
2023-10-17 21:46:08: (mod_wstunnel.c.433) http://localhost:3000 matches allowed origin: http://localhost:3000
2023-10-17 21:46:08: (mod_wstunnel.c.495) WebSocket Version = 13
2023-10-17 21:46:08: (mod_wstunnel.c.542) will recv binary data from backend
2023-10-17 21:46:08: (response.c.384) -- logical -> physical
2023-10-17 21:46:08: (response.c.386) Doc-Root     : /users/glenne/git/holden-loadcontrol/webclient/build
2023-10-17 21:46:08: (response.c.388) Basedir      : /users/glenne/git/holden-loadcontrol/webclient/build
2023-10-17 21:46:08: (response.c.390) Rel-Path     : /nlcsock
2023-10-17 21:46:08: (response.c.392) Path         : /users/glenne/git/holden-loadcontrol/webclient/build/nlcsock
2023-10-17 21:46:08: (gw_backend.c.1031) connect delayed; will continue later: tcp:127.0.0.1:9000
2023-10-17 21:46:08: (gw_backend.c.265) got proc: pid: 0 socket: tcp:127.0.0.1:9000 load: 1
2023-10-17 21:46:08: (mod_wstunnel.c.844) send handshake response
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: HTTP/1.1 101 Switching Protocols
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: Upgrade: websocket
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: Sec-WebSocket-Accept: QHWDMbHFruge3+2tJc0rKgUAXFI=
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: Sec-WebSocket-Protocol: binary
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: Connection: upgrade
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: Date: Wed, 18 Oct 2023 01:46:08 GMT
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: Server: lighttpd/1.4.72
2023-10-17 21:46:08: (h1.c.248) fd:8 resp: 
2023-10-17 21:46:08: (gw_backend.c.345) released proc: pid: 0 socket: tcp:127.0.0.1:9000 load: 0
2023-10-17 21:46:08: (gw_backend.c.1117) proc: tcp:127.0.0.1:9000 0 0 0 0

If I change the config to

wstunnel.frame-type = "text" 

and change the js and config to text, it works fine. Sends ABCD to the port 9000 and keeps the connection open.

import { w3cwebsocket } from 'websocket';
const  wsclient = new w3cwebsocket(`ws://${window.location.hostname}:8888/nlcsock`);

wsclient.onopen = () => {
   const byteArray = new Uint8Array(4);
   wsclient.send('ABCD');
};

2023-10-17 21:54:05: (gw_backend.c.1117) proc: tcp:127.0.0.1:9000 0 0 0 0
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: GET /nlcsock HTTP/1.1
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Host: localhost:8888
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Connection: Upgrade
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Pragma: no-cache
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Cache-Control: no-cache
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Upgrade: websocket
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Origin: http://localhost:3000
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Sec-WebSocket-Version: 13
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Accept-Encoding: gzip, deflate, br
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Accept-Language: en-US,en;q=0.9
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Cookie: nlc-login=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJubGMiLCJzdWIiOiJ3ZWJzb2NrZXQiLCJleHAiOjE2OTg3MjI3NDAsInVzZXJuYW1lIjoiYWRtaW4ifQ.me4v49UeFEOHkr_rTCqbzsbZv3b1qtc8-um3N5pxKKU
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Sec-WebSocket-Key: 3hEAV8+trRqHi3UM2KI+bQ==
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
2023-10-17 21:54:06: (h1.c.497) fd:8 rqst: 
2023-10-17 21:54:06: (configfile-glue.c.600) === start of condition block ===
2023-10-17 21:54:06: (configfile-glue.c.531) $HTTP["url"] =^ "/nlcsock" compare to /nlcsock
2023-10-17 21:54:06: (configfile-glue.c.388) 1 (uncached) result: true (cond: global / $HTTP["url"] =^ "/nlcsock")
2023-10-17 21:54:06: (response.c.295) -- parsed Request-URI
2023-10-17 21:54:06: (response.c.297) Request-URI     : /nlcsock
2023-10-17 21:54:06: (response.c.299) URI-scheme      : http
2023-10-17 21:54:06: (response.c.301) URI-authority   : localhost:8888
2023-10-17 21:54:06: (response.c.303) URI-path (clean): /nlcsock
2023-10-17 21:54:06: (response.c.305) URI-query       : 
2023-10-17 21:54:06: (gw_backend.c.981) gw - found a host 127.0.0.1 9000
2023-10-17 21:54:06: (gw_backend.c.2767) handling the request using wstunnel
2023-10-17 21:54:06: (mod_wstunnel.c.433) http://localhost:3000 matches allowed origin: http://localhost:3000
2023-10-17 21:54:06: (mod_wstunnel.c.495) WebSocket Version = 13
2023-10-17 21:54:06: (mod_wstunnel.c.548) will recv text data from backend
2023-10-17 21:54:06: (response.c.384) -- logical -> physical
2023-10-17 21:54:06: (response.c.386) Doc-Root     : /users/glenne/git/holden-loadcontrol/webclient/build
2023-10-17 21:54:06: (response.c.388) Basedir      : /users/glenne/git/holden-loadcontrol/webclient/build
2023-10-17 21:54:06: (response.c.390) Rel-Path     : /nlcsock
2023-10-17 21:54:06: (response.c.392) Path         : /users/glenne/git/holden-loadcontrol/webclient/build/nlcsock
2023-10-17 21:54:06: (gw_backend.c.1031) connect delayed; will continue later: tcp:127.0.0.1:9000
2023-10-17 21:54:06: (gw_backend.c.265) got proc: pid: 0 socket: tcp:127.0.0.1:9000 load: 1
2023-10-17 21:54:06: (mod_wstunnel.c.844) send handshake response
2023-10-17 21:54:06: (h1.c.248) fd:8 resp: HTTP/1.1 101 Switching Protocols
2023-10-17 21:54:06: (h1.c.248) fd:8 resp: Upgrade: websocket
2023-10-17 21:54:06: (h1.c.248) fd:8 resp: Sec-WebSocket-Accept: MWWqXSRURIIjra4ViUY1wHNDZCc=
2023-10-17 21:54:06: (h1.c.248) fd:8 resp: Connection: upgrade
2023-10-17 21:54:06: (h1.c.248) fd:8 resp: Date: Wed, 18 Oct 2023 01:54:06 GMT
2023-10-17 21:54:06: (h1.c.248) fd:8 resp: Server: lighttpd/1.4.72
2023-10-17 21:54:06: (h1.c.248) fd:8 resp: 
2023-10-17 21:54:06: (mod_wstunnel.c.1126) recv data from client (fd=8), size=a
2023-10-17 21:54:06: (mod_wstunnel.c.1142) type = text
2023-10-17 21:54:06: (mod_wstunnel.c.1198) specified payload size=4
2023-10-17 21:54:06: (mod_wstunnel.c.1245) read payload, size=4
2023-10-17 21:54:06: (mod_wstunnel.c.1251) rest of frame size=0
2023-10-17 21:54:06: (gw_backend.c.1117) proc: tcp:127.0.0.1:9000 0 0 1 0

From a quick look at the logs:

2023-10-17 21:46:08: (gw_backend.c.1031) connect delayed; will continue later: tcp:127.0.0.1:9000
2023-10-17 21:46:08: (gw_backend.c.265) got proc: pid: 0 socket: tcp:127.0.0.1:9000 load: 1

2023-10-17 21:54:06: (gw_backend.c.1031) connect delayed; will continue later: tcp:127.0.0.1:9000
2023-10-17 21:54:06: (gw_backend.c.265) got proc: pid: 0 socket: tcp:127.0.0.1:9000 load: 1
2023-10-17 21:54:06: (mod_wstunnel.c.844) send handshake response
...
2023-10-17 21:54:06: (mod_wstunnel.c.1126) recv data from client (fd=8), size=a

If you get a chance, please dtruss lighttpd and see what lighttpd receives from the client when type = "binary". I am most interested in the kqueue events and if read()/recv() fails, or gets EOF, or gets a number of websocket-framed bytes from the client, and if lighttpd receives any socket events from the backend which might indicate that the connection should be closed.

It may take me a few days to dig up an old mac on which to test your scenario above.

Has anyone successfully used the frame-type binary?

Yes, a long time ago, I wrote the example using noVNC and wstunnel.frame-type = "binary" and tested it on Linux.
Example: websocket tunnel to VNC server via noVNC client

https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/binaryType

Have you tried setting the binaryType attribute in your javascript? From the example linked above:

// Create WebSocket connection.
const socket = new WebSocket("ws://localhost:8080");

// Change binary type from "blob" to "arraybuffer" 
socket.binaryType = "arraybuffer";

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer

Note in the first bit of code I had the binaryType set to arraybuffer.

I did a wireshark trace (attached) and indeed, the requesting client is the one closing the socket after getting a Switching protocols request. The one that succeeds is using the same browser configuration (binaryType='arraybuffer') as the one that fails. Basically the same code connecting to a different websocket server so the server responses are perhaps key to why the browser likes one and not the other.

One that fails:

Frame 13: 279 bytes on wire (2232 bits), 279 bytes captured (2232 bits) on interface 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 8888, Dst Port: 57165, Seq: 1, Ack: 696, Len: 223
Hypertext Transfer Protocol
    HTTP/1.1 101 Switching Protocols\r\n
    Upgrade: websocket\r\n
    Sec-WebSocket-Accept: 1MtIFD6PjA3UFpmE4E0FLF41o5c=\r\n
    Sec-WebSocket-Protocol: binary\r\n
    Connection: upgrade\r\n
    Date: Wed, 18 Oct 2023 03:51:55 GMT\r\n
    Server: lighttpd/1.4.72\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.015892000 seconds]
    [Request in frame: 7]

One that works:

Frame 9: 237 bytes on wire (1896 bits), 237 bytes captured (1896 bits) on interface 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 8000, Dst Port: 51209, Seq: 1, Ack: 689, Len: 181
Hypertext Transfer Protocol
    HTTP/1.1 101 Switching Protocols\r\n
    Sec-WebSocket-Accept: J02hMO652W7L6EOLkBmPMqQGH+A=\r\n
    Upgrade: websocket\r\n
    Connection: Upgrade\r\n
    Server: ixwebsocket/11.4.4 macos nossl zlib 1.2.11\r\n
    \r\n
    [HTTP response 1/1]
    [Time since request: 0.001500000 seconds]
    [Request in frame: 7]

Note in the first bit of code I had the binaryType set to arraybuffer.

Sorry. I had overlooked that.

For HTTP/1.1, Sec-WebSocket-Accept is calculated the same way for both "text" and "binary", based on client-provided Sec-WebSocket-Key, so that is less likely to be what makes a difference.

Maybe the client does not like Sec-WebSocket-Protocol: binary? Is there any way you could test with a different client? Are you using Safari? Have you tried Firefox? Chrome?
Maybe you could overwrite that response header with a blank value to cause lighttpd to remove it?
server.modules += ("mod_setenv")
setenv.set-response-header = ("Sec-WebSocket-Protocol" => "")

If you enable HTTP/2 (enabled by default in lighttpd), then the browser might try to use HTTP/2 extended CONNECT to make the websocket connection with lighttpd (WebSockets over HTTP/2 #3151). Does that work?

I've been using Chrome but I verified Safari behaves the same way.

Good News! With the change to remove the Sec-WebSocket-Protocol header the websocket successfully connects and is able to transport data on both Chrome and Safari. I'll try my primary target app later today but from the test program this change looks like it solves the problem. Guess the open question is why the header is causing a rejection. Love how configurable lighttpd is!

https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

Warning: The server can't send more than one Sec-Websocket-Protocol header. If the server doesn't want to use any subprotocol, it shouldn't send any Sec-WebSocket-Protocol header. Sending a blank header is incorrect. The client may close the connection if it doesn't get the subprotocol it wants.

Technically, the client should send Sec-WebSocket-Protocol to request a subprotocol, and the server should respond with Sec-WebSocket-Protocol if one of the choices is selected. Many websocket clients, especially older ones implementing websockets prior to RFC 6455, do not send Sec-WebSocket-Protocol and assume frame-type "text". If you configured lighttpd to expect frame-type "binary", lighttpd mod_wstunnel sends Sec-WebSocket-Protocol: binary in the response headers for the websocket upgrade request. Perhaps this is not well-tolerated in modern browsers. Alternatively, maybe Chrome and Safari are sending Sec-WebSocket-Protocol and lighttpd is not picking from the client-provided list. Would you please see which request headers are being sent when requesting websocket upgrade?

I have not looked, but I wonder if you can specify ws.binaryType = "arraybuffer"; in the constructor for the websocket object and if that would make a difference. I am guessing that the client javascript is creating the websocket connection (assuming frame-type "text") and rejecting Sec-WebSocket-Protocol: binary response header before processing ws.binaryType = "arraybuffer"; Just spit-balling; I do not frequently do client-side development.

I think that I am going to modify lighttpd mod_wstunnel to omit sending Sec-WebSocket-Protocol response header unless client sends Sec-WebSocket-Protocol with a token recognized by mod_wstunnel.

--- a/src/mod_wstunnel.c
+++ b/src/mod_wstunnel.c
@@ -822,7 +822,7 @@ static int create_response_rfc_6455(handler_ctx *hctx) {
     buffer_append_base64_encode(value, sha_digest, SHA_DIGEST_LENGTH, BASE64_STANDARD);
   }

-    if (hctx->frame.type == MOD_WEBSOCKET_FRAME_TYPE_BIN)
+    if (1 == hctx->subproto)
         http_header_response_set(r, HTTP_HEADER_OTHER,
                                  CONST_STR_LEN("Sec-WebSocket-Protocol"),
                                  CONST_STR_LEN("binary"));

With the above patch, if someone needed the (current) behavior in lighttpd mod_wstunnel to unconditionally send Sec-WebSocket-Protocol: binary" response header when wstunnel.frame-type = "binary" is set in lighttpd.conf, they can use mod_setenv to unconditionally send that header:
server.modules += ("mod_setenv")
setenv.set-response-header = ("Sec-WebSocket-Protocol" => "binary")
(and they should scope that to requests handled by mod_wstunnel in a lighttpd.conf conditional)

I've been traveling so couldn't reply earlier.

Here is an example request below. No mention of Sec-WebSocket-Protocol

Frame 7: 751 bytes on wire (6008 bits), 751 bytes captured (6008 bits) on interface 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
Transmission Control Protocol, Src Port: 57165, Dst Port: 8888, Seq: 1, Ack: 1, Len: 695
Hypertext Transfer Protocol
    GET /nlcsock HTTP/1.1\r\n
    Host: localhost:8888\r\n
    Connection: Upgrade\r\n
    Pragma: no-cache\r\n
    Cache-Control: no-cache\r\n
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36\r\n
    Upgrade: websocket\r\n
    Origin: http://localhost:3000\r\n
    Sec-WebSocket-Version: 13\r\n
    Accept-Encoding: gzip, deflate, br\r\n
    Accept-Language: en-US,en;q=0.9\r\n
    Cookie: nlc-login=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJubGMiLCJzdWIiOiJ3ZWJzb2NrZXQiLCJleHAiOjE2OTg3MjI3NDAsInVzZXJuYW1lIjoiYWRtaW4ifQ.me4v49UeFEOHkr_rTCqbzsbZv3b1qtc8-um3N5pxKKU\r\n
    Sec-WebSocket-Key: Wbn08KSb2K6rafQFgfxCKw==\r\n
    Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits\r\n
    \r\n
    [Full request URI: http://localhost:8888/nlcsock]
    [HTTP request 1/1]
    [Response in frame: 13]

Thanks. I plan to make the one line change in patch further above for the next release of lighttpd. If you can test that works for you (without needs to overwrite using setenv.set-response.header), that would be a nice confirmation.

BTW, depending on how you want your environment to work, you can configure mod_wstunnel to handle requests to /nlcsock on your main site. If using TLS (https://localhost/nlcsock), then popular browsers may attempt to use HTTP/2 extended CONNECT to initiate a websocket connection with lighttpd.

Yes, I use the 8888 for testing but have verified it works on the main site as well. I'll have to build lighttpd from source to test the patch however which will have to wait till next week since I'm traveling. Thanks for your quick response to the issue!

Patch posted above is part of lighttpd 1.4.73