Is websocket listener broken?

[cmidgley]

Build environment: Windows
Moddable SDK version: 5.6.0
Target device: Windows

Description
I finally pulled latest (I've been staying stable on an October pull), and I'm finding that the io HTTP server / web socket listener handoff isn't working. I reverted to pure 5.6.0 (with none of my merges) and the sample code at examples/io/listener/httpserver demonstrates the same failure.

Steps to Reproduce

1. Build and run examples/io/listener/httpserver
2. No WebSocket onMessage trace messages will appear.

It appears that the client makes the connection and receives the completed negotiation from the server, and even sends the first "hello" message, but nothing more happens. The server never does a handoff because onDone on the WebSocketHandshake route is never called.

[cmidgley]

In examples/io/listener/httpserver/httpserver.js, I see that this.#remaining is used somewhat inconsistently - it is sometimes used as a number, sometimes as a boolean, and occasionally set to undefined. What appears to be happening here is that this.#remaining is set to undefined (in respond()) and in #onWritable (state sendResponseBody) it is being checked specifically for numeric value 0 which of course doesn't match as it is undefined. Changing it to if (!this.#remaining) appears to fix this issue, but other uses may be incorrect.

[phoddie]

It is broken! It happened when fixing #1448.

HTTP is messy. The length of the response body is specified in several ways:

1. Content-Length header explicitly states the length
2. Transfer-Encoding of chunked means the response is unknown but sender will signal the end with an empty chunk
3. Neither of these, the response body is whatever is transmitted until the socket is closed

It was (3) that got fixed in #1448 to allow the web camera server to send an infinite stream of JPEG images.

The problem is that the list above is incomplete. It is missing this:

4. Switching Protocol responses have an implicit content-length of 0. RFC 2616 section 10.1.2 explains that "The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response."

That's this case. My tentative solution is to force #remaining to 0 on a 101 response:

				case "sendResponseHeader": {
					const item = this.#options.headers.next();
					if (item.done) {
						this.#pendingWrite = "\r\n";
						this.#state = "sendResponseBody";
						if (101 === this.#options.status)	// 101 Switching Protocols ...the empty line which terminates the 101 response
							this.#remaining = 0;
						delete this.#options.headers;
					}

That seems better here. What do you see?

---

I should have noted above that the Switching Protocols response does not contain Content-Length or transfer-encoding header and so appears to fall into case (3) above. The special case proposed above forces an empty response body.

[cmidgley]

Confirmed here as well. Thanks for jumping on it.