When it breaks - three ways to get one response wrong

In your scratch copy, remove the single field line that frames the body. Delete the content-length line from the head and nothing else. Keep the connection open (don't close the socket).

Start it, and limit curl to three seconds. curl is a command-line HTTP client. --max-time 3 stops the command after three seconds. $? is a shell variable which holds the previous command's numeric exit status. Exit status of zero means success, and a nonzero status means some failure happened.

curl -s --max-time 3 http://127.0.0.1:3124/ ; echo "exit: $?"

Hello, World!
exit: 28

The body arrived, but curl still kept waiting. Then it exited with 28, which is the curl code for an operation timeout. Run it in verbose mode to print the protocol details.

curl -sv --max-time 3 http://127.0.0.1:3124/ 2>&1 | grep -iE 'no chunk|timed out|Closing'

* no chunk, no close, no size. Assume close to signal end
* Operation timed out after 3006 milliseconds with 13 bytes received
* Closing connection

2>&1 sends standard error to the same pipe as standard output. Standard output is the normal command result, and standard error carries the diagnostics. grep -iE filters both streams with a case-insensitive extended regular expression. The quoted alternatives keep only the lines containing no chunk, timed out, or Closing.

"No chunk, no close, no size" refers to chunked coding, connection close, and content-length. You supplied none of them and kept the socket open, so curl sat waiting for a connection close. Put the field line back and the response finishes after 13 body bytes.

In the scratch copy, replace every \r\n in the head with a bare \n. Leave the body as it is.

curl accepts it without any complaint. The spec lets a recipient treat a lone LF as a line terminator, and curl uses that freedom.

curl -s -i http://127.0.0.1:3125/

HTTP/1.1 200 OK
content-length: 13

Hello, World!

Now send the same request with Node's fetch function. fetch returns a Promise for an HTTP response. Node implements it with an HTTP client library called Undici.

node -e 'fetch("http://127.0.0.1:3125/").then(r=>r.text()).then(console.log).catch(e=>console.log("REJECTED:", e.cause?.message ?? e.message))'

REJECTED: Response does not match the HTTP/1.1 protocol (Missing expected CR after response line)

Undici's parser requires the CR and reports Missing expected CR after response line. The RFC keyword MAY permits a recipient to accept a bare LF, but it doesn't require it. So both client behaviours conform to the rule. A conforming sender always emits CRLF, no exceptions.

In the scratch copy, make two changes. Set the body to something with a multibyte character, like Hello, Wörld!, and take the length from .length instead of Buffer.byteLength. A multibyte character uses more than one byte in the selected byte encoding.

// This uses UTF-16 code units instead of encoded bytes.
"content-length: " + body.length

The two counts disagree by exactly one.

node -e 'const s="Hello, Wörld!"; console.log("str.length:", s.length, "byteLength:", Buffer.byteLength(s))'

str.length: 13 byteLength: 14

You advertise 13, but the body is actually 14 bytes. The client trusts the number, reads 13, and cuts off the last byte.

curl -s http://127.0.0.1:3126/

Hello, Wörld

The final ! is gone. The client consumed 13 out of the 14 bytes and stopped one short. On a reused connection, that leftover byte would become the first byte of the next response - and that is corruption, not just a visible truncation.

content-length counts octets. str.length counts UTF-16 code units, which is neither octets nor characters. For any body with a non-ASCII byte, the two diverge, and the client either truncates (too small) or hangs (too large). The fix is the same one your real hello.js already uses - Buffer.byteLength(str).