Node adapter `sendNodeResponse` loses `set-cookie` header when setting multiple cookies at once

[zgq354]

Environment

Node Version: v20.19.2
Package Version: srvx@0.9.5

Describe the bug

Node adapter's sendNodeResponse loses set-cookie header when set multiple cookie at once

Reproduction

See: https://stackblitz.com/edit/srvx-multi-header-demo?file=run.mjs

When we set header before sendNodeResponse, only one set-cookie header remains at response. If we remove the setHeader, the result is as expected.

Background

I'm building a full-stack web app with TanStack Start and setting up a JWT authentication middleware that uses both access token and refresh token with cookie. However, I encountered an issue where the Set-Cookie header isn't working in the local development server.

TanStack Start builds a vite dev server plugin that uses NodeRequest and sendNodeResponse to convert Node.js-style requests and responses into the fetch handler pattern.

Plugin Code: https://github.com/TanStack/router/blob/854a7ef23dcd7b986af32e4efbb91861af58b9ca/packages/start-plugin-core/src/dev-server-plugin/plugin.ts#L3

Conclusion & Proposed fix

The root cause is in the Node.js HTTP Server's writeHead function (node/lib/_http_server.js). When we setHeader first, writeHead will override previous headers with same keys and only the last one preserved.

The proposed fix is merge the duplicated key header into array first, then call the writeHead with the merged header array value.

I just implement this on my fork, and create some unit tests.

Happy to submit a PR if above approach sounds good. 👀

[pi0]

Thanks for reporting issue.

I see in your repro example, you are setting headers both on nodeRes.setHeader('x-test', 'test'); and web APIs. It should not happen in normal situations where you use res.headers (web API) to append prepared headers in tss route middleware.

So wondering why we need this? (and if this needs to be behind a flag as merging is both costly and can have unwanted consequences like duplicate set-cookie)

[zgq354]

Thanks for your fast response!

I am trying to build an "auth context middleware" to transparently finish the token refresh process, and use it as a global request middleware in tss project, not a route middleware.

Example code is like this, it will do 2 things:

1. Automatically check the access token and use refresh token to generate a new token, then it set both new refresh token and new access token cookie via Response Set-Cookie header.
2. build an auth context data and pass it to the next middleware / route handler.

Setting multiple cookies in a single response is a common use case. However, the RFC specification requires each cookie to be sent using a separate Set-Cookie header, so we need to support multiple headers in a HTTP response.

x-test: test is just a randomly example, I've looked into the real use case and found that the vite dev server will set the Vary: origin header first, because of the config will enable the cors feature by default, which trigger the issue I post above.

Another temp debug repo here for reference: https://github.com/zgq354/tss-middleware-cookie-debug