fix(server): don't 404 non-websocket upgrade probes, and keep the body on every supported Node

[jpr5]

Carries @dennisoelkers' fix from #410 (their four commits, authorship intact) and adds the piece needed to make it correct on every Node this package supports. Closes #410.

Their fix

Node fires "upgrade" rather than "request" for any Connection: Upgrade header, whatever protocol is named. langchain4j's OkHttp client speculatively sends Upgrade: h2c on plain requests to probe for HTTP/2 cleartext, so GET /api/tags and POST /api/chat landed in the WebSocket-only handler and took an unconditional 404. The fix replays the request with Upgrade/Connection stripped and lets Node re-parse it as an ordinary request. Diagnosis and approach are both right.

I verified the parts that worried me, since this is raw socket work:

• real WebSocket upgrades still get 101, including the mixed-case Upgrade: WebSocket form
• the replayed request still passes the AIMOCK_API_KEYS boundary — an unauthenticated h2c probe gets 401, not a bypass
• keep-alive reuse of the same socket after a replay works: two requests, two 200s
• no listener growth on the server across 25 probes

What this adds: where the body lives is version-dependent

The original replay forwards head. That is only where the body is on some versions:

• Node ≤ 24 detaches the parser at "upgrade", so req yields nothing and the body lands in head — or arrives on the socket afterwards if the client sent it later.
• Node ≥ 26 parses the body onto req and leaves head empty. The bytes are on neither the socket nor head.

So on Node 26 a head-only replay left the re-parsed request waiting on a Content-Length worth of bytes that never arrived — no data, no end, no error. The connection hung open instead of answering, which is worse than the 404 it replaced: a 404 fails a test in milliseconds, a hang blocks the caller until its own timeout. engines is >=20.15.0, so Node 26 is declared supported.

Measured on a dependency-free reproduction of just the replay technique:

node 20/22/24   GET 200 | POST 200 | POST delayed 200 | POST 200KB 200
node 26         GET 200 | POST (NO RESPONSE) | POST delayed (NO RESPONSE) | POST 200KB (NO RESPONSE)

Instrumenting it showed the headers parse fine on 26 — right method, right URL, correct content-length — and pinpointed where the bytes went:

node 24   cl=7  head=7B  socketAfter=0B
node 26   cl=7  head=0B  socketAfter=0B     ← and req yields "{"a":1}"

The fix: drain req and concat it into the replay. The stream has already ended in both cases, so it never waits on the network — on Node ≤ 24 it yields zero bytes and head carries the body exactly as before. All four probe shapes now pass on 20, 22, 24 and 26.

Worth noting the earlier reformulations that did not help, since they look plausible: a 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 rather than re-emitting the socket. None move the needle, because the problem was never the socket — the bytes simply weren't in head.

Tests

Two added beside the original. The existing test asserts the body was parsed — but a validation error only needs enough of the body to see a field is missing, so it would still pass on a truncated replay. The new ones assert the body arrived intact (matching a fixture on its content, which truncation cannot fake) and that a 200KB body survives, which no single read can carry.

Mutation-tested: dropping parsedBody from the concat reds 3 of the 95 tests in the file; restored, 95 pass.

CI matrix

Adds Node 26 to the unit and pytest matrices. It sits inside the declared engines range and was untested — which is exactly why the body-loss case passed CI on the original PR.

Verification

typecheck (all three configs) exit 0 · full suite 183 files / 5694 tests · eslint and prettier clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y445N6QQBeAdiLcEvEpqGe

[pkg-pr-new]

Open in StackBlitz

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

commit: a6f66be