fix(server): don't 404 non-websocket upgrade probes like h2c

[dennisoelkers]

Node fires the "upgrade" event (not "request") for any request with a Connection: Upgrade header, regardless of the target protocol. langchain4j speculatively sends Upgrade: h2c on plain requests to probe for HTTP/2 cleartext, which made GET /api/tags and POST /api/chat (for ollama) land in the WebSocket-only upgrade handler and get an unconditional 404.

Only treat the request as a WebSocket upgrade when Upgrade: websocket is actually present; otherwise fall through to the normal HTTP pipeline so routes like /api/tags still work.

[dennisoelkers]

@jpr5: Do you think you will have some time too look at this? Fixing this is a prerequisite for us to be able to use it in our project :/

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@copilotkit/aimock@410

commit: c597453

[jpr5]

Thanks for this — the diagnosis is right, the write-up is clear, and the raw-socket regression tests are the correct way to exercise a shape http.request() can't produce. GET /api/tags is genuinely fixed, and I verified the guard doesn't break real upgrades: Upgrade: websocket still gets 101, including the mixed-case Upgrade: WebSocket form (your .toLowerCase() handles the RFC's case-insensitive token correctly), keep-alive reuse after a replay works — two requests on one socket, two 200s — and there's no listener growth on the server across 25 probes.

I'm holding the merge on one finding.

Any h2c-probed request with a body hangs forever on Node 26

CI is green because the matrix is [20, 22, 24]. package.json declares engines: {"node": ">=20.15.0"}, which is open-ended, so Node 26 is a version this package claims to support — and it's what a contributor on a current Homebrew/nvm install gets today.

Dependency-free reproduction of just the replay technique (no aimock, no vitest — http.createServer plus your upgrade handler verbatim), run across the matrix and one version past it:

### node:20   GET 200 | POST same-write 200 | POST delayed 200 | POST 200KB 200
### node:22   GET 200 | POST same-write 200 | POST delayed 200 | POST 200KB 200
### node:24   GET 200 | POST same-write 200 | POST delayed 200 | POST 200KB 200
### node:26   GET 200 | POST same-write (NO RESPONSE) | POST delayed (NO RESPONSE) | POST 200KB (NO RESPONSE)

Instrumenting the handler shows exactly where it diverges. The rebuilt headers parse fine on both — same method, same URL, correct content-length — but on Node 26 the unshifted body bytes are never delivered to the re-parsed request:

node v24.20.0
    [handler fired] POST /x content-length=7
    [data] 7B
    [end] total=7B
  POST body same write: HTTP/1.1 200 OK

node v26.8.1
    [handler fired] POST /x content-length=7
  POST body same write: (NO RESPONSE)

No data, no end, no error, no aborted. The request never completes, so nothing ever responds and the connection stays open.

This is what makes it worth blocking on rather than filing: it is strictly worse than the current behaviour on that version. On main today, both requests answer immediately —

main: h2c GET  /api/tags: HTTP/1.1 404 Not Found [immediate]
main: h2c POST /api/chat: HTTP/1.1 404 Not Found [immediate]

— so on Node 26 this trades a wrong-but-fast 404 for an indefinite hang. For a mock server that's the bad direction: a 404 fails a test in milliseconds with a legible symptom, while a hang blocks until the caller's own timeout, which is exactly the situation aimock exists to keep people out of. Your own POST /api/chat test reproduces it — it fails locally at the 15s vitest timeout on Node 26.

I tried the obvious reformulations and none of them help on 26: single Buffer.concat([rebuilt, head]) instead of two unshifts, socket.resume() after the emit, and deferring the emit to process.nextTick. So it isn't unshift ordering — something about how a re-emitted connection's parser sources its body changed, and it needs a different approach rather than a tweak.

What would unblock it

Whichever you prefer:

1. Scope the replay to bodyless requests. A request with no content-length and no transfer-encoding replays correctly on every version tested, including 26 — that covers GET /api/tags, the case in your report. Anything carrying a body keeps today's behaviour, so no hang is introduced anywhere.
2. Keep the body path but make failure loud. If the replay can't be made to work on 26, detect it and answer — even a 501/505 beats holding the socket open.
3. Add the current Node to the CI matrix either way. Node 26 is inside the declared engines range and CI can't see it, which is why this passed. Happy to do that as a separate change if you'd rather not widen this PR.

Option 1 plus a Node 26 matrix entry is the smallest thing that ships the fix you reported without regressing anyone, if you want the narrow path.

Full repro script and per-variant results available if useful — say the word and I'll paste it or push it as a test.

[jpr5]

Solved — and it turned out not to be fixable by adjusting the replay, so I've opened #418, which carries your four commits with authorship intact and adds the missing piece on top. Credit is yours; closing this in favour of that one.

The root cause, for the record: the bytes were never in head on Node 26.

node 24   cl=7  head=7B  socketAfter=0B
node 26   cl=7  head=0B  socketAfter=0B

Node ≥ 26 parses an upgrade request's body onto req and leaves head empty — req yields {"a":1} there, while on Node ≤ 24 it yields nothing and head carries the body. So a head-only replay was forwarding an empty body and the re-parsed request sat waiting on a Content-Length that would never be satisfied. Draining req and concatenating it into the replay covers both: the stream has already ended in either case, so it never waits on the network, and on Node ≤ 24 it contributes zero bytes and your original path is unchanged. All four probe shapes now pass on 20, 22, 24 and 26.

For anyone who finds this later, the reformulations that looked promising and did nothing: single Buffer.concat([rebuilt, head]) instead of two unshifts, socket.resume() after the emit, deferring the emit to process.nextTick, and bridging through a fresh Duplex instead of re-emitting the socket. None of them helped, because the problem was never the socket handling — your replay mechanics were correct all along.

#418 also adds Node 26 to the unit and pytest CI matrices. It's inside the declared engines range (>=20.15.0) and wasn't being tested, which is the only reason this got as far as a green CI run.

Thanks for the report and the fix — the raw-socket regression tests in particular were the right call, and they're what made the remaining gap easy to characterise.

[dennisoelkers]

Hey @jpr5, thanks for taking care of this, the quick review + fix! Much appreciated!