node-server

This PR fixes #400 while also optimizing Content-Length handling on the HTTP/1 response fast paths. I confirmed that copying the header record, as suggested in #400, also resolves the issue. In local benchmarks with Hono 4.13.8, that approach showed a performance regression on Node 20, but no clear regression on Node 22 or 24. It remains a reasonable option to consider. #401 already implements that approach. However, the original reporter offered, “Happy to open a PR if the approach looks right.” If we decide to proceed with the copying approach, I think we should respect that offer, close #401 for now, and give the reporter the opportunity to submit their PR. Implementation This PR uses Node’s internal field to let Node serialize the length without copying caller-owned header records. The same mechanism also handles responses without custom headers, avoiding explicit Content-Length header processing. This deliberately depends on Node.js implementation details, including private response fields whose behavior is not guaranteed by the public API. node-server has made similar implementation-dependent optimizations several times before. Given the measured improvements in the response fast paths, I consider the gains substantial enough to justify this dependency. Compatibility guards retain explicit-length fallbacks for HTTP/2 and other cases where automatic serialization cannot preserve the existing behavior. The regression tests check both response correctness and whether the intended fast paths are used. These tests run in the existing Node.js CI matrix, so incompatible changes should be detected promptly when an affected Node.js release is tested. Benchmarks The final implementation was compared with the baseline (, v2.1.0) and a plain-header-copy variant on an Apple M5 Pro (arm64, macOS). Each variant ran in five independent processes, with rotating execution order. Each process performed 300,000 warm-up requests followed by five samples of 200,000 requests, using natural GC. The table reports median time per request in nanoseconds; lower is better. This includes Hono dispatch, response creation, and Node’s header serialization. Socket I/O is excluded. In these runs, copying increased processing time by 33.89% on Node 20, while showing no slowdown on Node 22 or 24. The copy column measures the benchmark harness’s plain-record-copy implementation, rather than the exact #401 implementation. A control case using JSON with seven additional headers exercises the conversion path. Its median changes were −1.42%, −0.72%, and −0.47% on Node 20, 22, and 24 respectively, with overlapping baseline and candidate ranges. These small differences do not establish an improvement on that path.

Fixes #400 Description In , when is a plain object and no was specified, mutated the caller's header object in place. If that header object is reused across responses (e.g., a module-level constant) or frozen via : 1. On reused plain headers, subsequent requests trigger a (HTTP 500) because Hono's response handler iterates non-string values as multi-value headers. 2. On frozen headers, direct mutation throws (HTTP 500). Solution Instead of mutating the incoming object in place, create a shallow copy with only when it needs to be injected: Tests Added parameterized tests covering , , and bodies to ensure caller header objects remain unmodified across sequential requests. Added test verifying frozen header objects () do not cause runtime errors. Verified all 439 tests pass cleanly.

What version of are you using? 2.1.1 (with 4.13.8, Node v24.19.0, macOS) What is the problem? When a handler passes a plain object as the third argument of , the adapter writes into that object. If the object is reused across responses — a module-level constant, for example — the next response fails with and the server returns 500. So the first request succeeds and every subsequent one fails, which is an unpleasant failure mode to debug: it looks like a caching or concurrency problem rather than a mutated constant. Minimal reproduction Output: Cause In , when is a plain object the is assigned directly to it: https://github.com/honojs/node-server/blob/main/src/listener.ts#L228-L235 The and array branches just above build a new object via , so only the plain-object path mutates its input. Since Hono keeps the caller's object as the response's header init, that write lands on the object the handler owns. The 500 on the following request then comes from Hono's side: walks the header record and treats any non-string value as an iterable of values, and is now a number: Why it is easy to miss never goes through this adapter, so a test suite that exercises handlers in-process passes cleanly while production fails from the second request onward. In our case the bug reached a deployed service with full coverage of the affected route. Suggested fix Copy before writing, so the caller's object is left as it was: Using a string value would also be more consistent with the rest of the header record, though the copy is the part that fixes the reuse case. Happy to open a PR if the approach looks right.